> > 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 <n...@nickallen.org> 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? >
