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. That still leaves room for necessary patches on a given release line. If you’all think something more complex is needed, please propose. When we reach consensus, I can edit the Release Process to document it. Cheers, --Matt On 11/16/17, 6:34 AM, "[email protected]" <[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 On Thu, Nov 16, 2017 at 9:10 AM Nick Allen <[email protected]> wrote: > The code of the 'Kafka Plugin for Bro' is now maintained in the external > repository that we set up a while back. Do we need to change anything in > the release procedure to account for this? > -- Jon
