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, "zeo...@gmail.com" <zeo...@gmail.com> 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 <ottobackwa...@gmail.com>
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 (n...@nickallen.org) 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 <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?
> >
>
--
Jon
