I like the idea of associating a commit hash to a version of a package. I didn't consider that and it's clever. That would make development of package much more fluid and assure a 'point in time' version of any package.
My thoughts were to offer zero guarantee around package stability or trustworthiness to users (other than the package will install, uninstall, etc with broctl) unless the package is included in the Bro project. This would prevent the Bro team from having to manage too much. Package versioning, stability, and questions/support would be left up to package authors and package trustworthiness would be up to public reputation. This is generally how community apps are handled for Splunk. No matter how versioning is done, an announcement to all package authors should go out when new version of Bro are cut so to ensure interoperability. -AK On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke <[email protected]> wrote: > > On Oct 14, 2013, at 7:24 PM, anthony kasza <[email protected]> wrote: > >> My thought was for the universe database to contain the following >> pieces of information (taken from the project page): name, URL, >> author, tags, package version, Bro version, dependencies, license, >> description. > > I think that sounds ok, though details of how package versioning will work > may need some fleshing out up front. Maybe one question to answer first: > what level of stability and trustworthiness is expected from the universe? > > I'd say a git commit hash for versioning could give some of both. Stability > in that external repos can progress as fast as they want, but the universe > metadata should still point to a valid version. Trustworthiness in that it's > known a universe maintainer reviewed the code associated with the hash. > Problem is that a git commit hash is per-repository, but per-package > versioning might be needed (i.e. limit of one package per repo w/ this > scheme). > > - Jon On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke <[email protected]> wrote: > > On Oct 14, 2013, at 7:24 PM, anthony kasza <[email protected]> wrote: > >> My thought was for the universe database to contain the following >> pieces of information (taken from the project page): name, URL, >> author, tags, package version, Bro version, dependencies, license, >> description. > > I think that sounds ok, though details of how package versioning will work > may need some fleshing out up front. Maybe one question to answer first: > what level of stability and trustworthiness is expected from the universe? > > I'd say a git commit hash for versioning could give some of both. Stability > in that external repos can progress as fast as they want, but the universe > metadata should still point to a valid version. Trustworthiness in that it's > known a universe maintainer reviewed the code associated with the hash. > Problem is that a git commit hash is per-repository, but per-package > versioning might be needed (i.e. limit of one package per repo w/ this > scheme). > > - Jon On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke <[email protected]> wrote: > > On Oct 14, 2013, at 7:24 PM, anthony kasza <[email protected]> wrote: > >> My thought was for the universe database to contain the following >> pieces of information (taken from the project page): name, URL, >> author, tags, package version, Bro version, dependencies, license, >> description. > > I think that sounds ok, though details of how package versioning will work > may need some fleshing out up front. Maybe one question to answer first: > what level of stability and trustworthiness is expected from the universe? > > I'd say a git commit hash for versioning could give some of both. Stability > in that external repos can progress as fast as they want, but the universe > metadata should still point to a valid version. Trustworthiness in that it's > known a universe maintainer reviewed the code associated with the hash. > Problem is that a git commit hash is per-repository, but per-package > versioning might be needed (i.e. limit of one package per repo w/ this > scheme). > > - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
