I propose that we coordinate the review of METRON-1329 <https://github.com/apache/metron-bro-plugin-kafka/pull/4> and METRON-1313 <https://github.com/apache/metron/pull/847>, then merge METRON-1329, pursue a 0.1 release for apache/metron-bro-plugin-kafka, and then finalize METRON-1313 <https://github.com/apache/metron/pull/847> prior to the upcoming apache/metron release. At that point the roadmap outlined here <https://lists.apache.org/thread.html/286231d11fcb8349e0378d281a08d197876f80122056479156643104@%3Cdev.metron.apache.org%3E> will be complete, and both of the issues you outlined below would be addressed.
I did test making a bro package release of 0.4.2.0, and we can do that, but the related (nested) plugin version must be major.minor, so it would need to be something like 0.4 (or, my preference, 0.1). I would rather keep the package and plugin versions in line with each other than try to line the package version up with apache/metron versions, and have the plugin version out of whack (which is what people would see when checking to see if this package was properly installed - see the version here <https://github.com/apache/metron-bro-plugin-kafka/blob/master/tests/Baseline/kafka.show-plugin/output> ). Let me know what you all think - happy to discuss further. Jon On Thu, Nov 16, 2017 at 1:26 PM Matt Foley <[email protected]> wrote: > There’s two issues, I think: > (1) We’d like to be able to version and evolve the main body of Metron and > the metron-bro-plugin-kafka separately. > (2) We want to be able to assure that each release of Metron has a > known-working version of metron-bro-plugin-kafka > > At a very simple level, we can achieve these by > (1) Don’t put in version-checking constraints, or make those constraints > very loose and of a form that assumes forward-compatibility, ie “version of > metron-bro-plugin-kafka must be AT LEAST ‘x’ to be used with version ‘y’ of > Metron.” > (2) But we should still do an archive branch of metron-bro-plugin-kafka > when we make a release branch of Metron, unless the metron-bro-plugin-kafka > has zero changes since the last Metron release. > > I would recommend that we use a 4-element version for > metron-bro-plugin-kafka, and at least the first 3 elements should be equal > to the corresponding Metron release version. This isn’t necessary, but it > makes things easy to keep track of. That still leaves room for necessary > patches on a given release line. > > If you prefer other approaches, please propose. When we reach consensus, > I can edit the Release Process to document it. > Cheers, > --Matt > > On 11/16/17, 7:22 AM, "[email protected]" <[email protected]> wrote: > > I expect a few version changes up front to add some new features to the > package (0.1 for the initial release, 0.{2..n} for some new features, > 1.0 > when we stabilize) but after that it will probably only be updated to > follow kafka/librdkafka updates. > > Jon > > On Thu, Nov 16, 2017 at 10:10 AM Otto Fowler <[email protected]> > wrote: > > > How often to we expect to change this? If it is effectively pinned > then a > > release process is not that bad. > > > > > > On November 16, 2017 at 10:06:53, Nick Allen ([email protected]) > wrote: > > > > > > > > I would suggest that we institute a release procedure for the > package > > > itself, but I don't think it necessarily has to line up with metron > > > releases (happy to be persuaded otherwise). Then we can just link > metron > > > to metron-bro-plugin-kafka by pointing to specific > > > metron-bro-plugin-kafka releases (git tags > > > < > > > http://bro-package-manager.readthedocs.io/en/stable/package.html#package- > > > versioning> > > > ). > > > Right now, full-dev spins up against the > > > apache/metron-bro-plugin-kafka master branch, which is not a good > idea to > > > have in place for an upcoming release. That is the crux of why I > think we > > > need to finalize the move to bro 2.5.2 and the plugin packaging > before > > our > > > next release (working on it as we speak). > > > Jon > > > > > > I replayed Jon's comments from the other thread above. > > > > My initial thought, is that I would not want to manage two separate > release > > processes. I don't want to have a roll call, cut release candidates > and > > test both. > > > > I was thinking we would just need to change some of the > behind-the-scenes > > processes handled by the release manager. This is one area where I > had > > thought using a submodule in Git would help. > > > > > > > > > > > > > > > > > > > > On Thu, Nov 16, 2017 at 9:58 AM, Nick Allen <[email protected]> > wrote: > > > > > + Restarting the thread to include mentors. > > > > > > The code of the 'Kafka Plugin for Bro' is now maintained in the > external > > > repository that we set up a while back. > > > > > > - Metron Core: git://git.apache.org/metron.git > > > - Kafka Plugin for Bro: git://git.apache.org/ > > > metron-bro-plugin-kafka.git > > > > > > (Q) Do we need to change anything in the release procedure to > account for > > > this? > > > > > > -- > > Jon > > > > -- Jon
