You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Justin Leet <ju...@gmail.com> on 2018/09/07 14:26:38 UTC
[DISCUSS] Split apart releases for core Metron and the Bro plugin
Right now, we tie together our main release and the Bro plugin, as seen in
our 0.4.2 release
https://archive.apache.org/dist/metron/0.4.2/ and the current RC.
Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split apart these
releases within their dist directories.
In our case this might look something like
0.5.0/
metron-bro-plugin-kafka
- 0.2.0/
Right now, with the releases tied together, we aren't upgrading full-dev
with the version of the plugin (because we're releasing simultaneously and
can't update the version number).
If we split them apart, we can make the releases independently. This fixes
the problem of aligning the versions (simply release the plugin first,
update full-dev, release core Metron). The plugin also updates
substantially less often and we can just do those releases at a cadence we
choose.
Any thoughts on doing this?
Do we want try to get this separation done after the current release cycle
is over?
If we do, do we have a preferred layout? I didn't see anything Apache
preferred in a quick search, but I definitely could have missed something
(and https://checker.apache.org/projs/nifi.html looks clean for NiFi, so I
assume it's fine.)
Re: [DISCUSS] Split apart releases for core Metron and the Bro plugin
Posted by "Zeolla@GMail.com" <ze...@gmail.com>.
Good catch. I'm not sure what the right approach is there, I wonder what
other projects do for the same situation
Jon
On Mon, Oct 8, 2018 at 3:24 PM Justin Leet <ju...@gmail.com> wrote:
> https://github.com/apache/metron/pull/1188 scripts the creation of RC's.
> It does this split, and allows for independent releases. The main catch is
> a slight hangup with the KEYS file.
>
> The metron-bro-kafka-plugin repo doesn't contain a KEYS file, it currently
> has just been aligned with the main repo's KEYS file.The KEYS file doesn't
> need to live in each submodule's directory, just in the main folder (
> https://dist.apache.org/repos/dist/release/metron/). This means it's not
> a
> problem for the plugin repo to be missing it.
>
> The main catch is that right now, we only publish the KEYS file when we
> release the main repo. In the (admittedly rare) situation where we have a
> new release manager who has to update the KEYS file, we'd currently need to
> do a metron release before we could do a plugin release.
>
> Should we split out and document a KEYS update from the main repo?
> Essentially, just run through the normal PR process and then have a post
> merge step of kicking up the updated KEYS file. Then Release Process
> <https://cwiki.apache.org/confluence/display/METRON/Release+Process> would
> just get updated to reflect this process.
>
>
> On Fri, Sep 7, 2018 at 3:15 PM Casey Stella <ce...@gmail.com> wrote:
>
> > +1 to defer for this release and complete separation. Good fences make
> > good submodules. ;)
> >
> > On Fri, Sep 7, 2018 at 2:33 PM Zeolla@GMail.com <ze...@gmail.com>
> wrote:
> >
> > > +1 to defer for this release and +1 to Justin's suggested release/dist
> > > directory breakout and complete separation.
> > >
> > > Jon
> > >
> > > On Fri, Sep 7, 2018 at 1:43 PM Michael Miklavcic <
> > > michael.miklavcic@gmail.com> wrote:
> > >
> > > > +1 to deferring for this release and having the separation like NiFi.
> > > Since
> > > > we're bootstrapping from their process, what are they doing? I would
> > > assume
> > > > we'd want some sort of vote for the plugin version change as well.
> > > >
> > > > On Fri, Sep 7, 2018 at 10:15 AM Nick Allen <ni...@nickallen.org>
> wrote:
> > > >
> > > > > +1 for complete separation as you've described.
> > > > >
> > > > > On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <justinjleet@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > I would like this to be a complete separation. Complete with
> > > separate
> > > > > RCs,
> > > > > > separate call to vote, etc. There's a bit more overhead, but
> plugin
> > > > > > releases should be rarer and as the release infra gets improved
> and
> > > > > > scripted out more, I don't think it'll end up being much more
> than
> > > > > bundling
> > > > > > it together.
> > > > > >
> > > > > > On Fri, Sep 7, 2018 at 11:27 AM Nick Allen <ni...@nickallen.org>
> > > wrote:
> > > > > >
> > > > > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>,
> > split
> > > > > apart
> > > > > > > these releases within their dist directories.
> > > > > > >
> > > > > > > I prefer the way Nifi organizes it. Definitely seems more
> > > logically
> > > > > > > organized.
> > > > > > >
> > > > > > >
> > > > > > > > If we split them apart, we can make the releases
> independently.
> > > > This
> > > > > > > fixes the problem of aligning the versions (simply release the
> > > plugin
> > > > > > > first, update full-dev, release core Metron).
> > > > > > >
> > > > > > > Does this entail a complete separation; including a separate
> > > > > > call-to-vote?
> > > > > > > One vote for core Metron and a separate vote for plugin?
> > > > > > >
> > > > > > >
> > > > > > > > Do we want try to get this separation done after the current
> > > > release
> > > > > > > cycle is over?
> > > > > > >
> > > > > > > +1 Let's wait for the next release to hash this out.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <
> > justinjleet@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Right now, we tie together our main release and the Bro
> plugin,
> > > as
> > > > > seen
> > > > > > > in
> > > > > > > > our 0.4.2 release
> > > > > > > > https://archive.apache.org/dist/metron/0.4.2/ and the
> current
> > > RC.
> > > > > > > >
> > > > > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>,
> > split
> > > > > apart
> > > > > > > > these
> > > > > > > > releases within their dist directories.
> > > > > > > >
> > > > > > > > In our case this might look something like
> > > > > > > > 0.5.0/
> > > > > > > > metron-bro-plugin-kafka
> > > > > > > > - 0.2.0/
> > > > > > > >
> > > > > > > > Right now, with the releases tied together, we aren't
> upgrading
> > > > > > full-dev
> > > > > > > > with the version of the plugin (because we're releasing
> > > > > simultaneously
> > > > > > > and
> > > > > > > > can't update the version number).
> > > > > > > >
> > > > > > > > If we split them apart, we can make the releases
> independently.
> > > > This
> > > > > > > fixes
> > > > > > > > the problem of aligning the versions (simply release the
> plugin
> > > > > first,
> > > > > > > > update full-dev, release core Metron). The plugin also
> updates
> > > > > > > > substantially less often and we can just do those releases
> at a
> > > > > cadence
> > > > > > > we
> > > > > > > > choose.
> > > > > > > >
> > > > > > > > Any thoughts on doing this?
> > > > > > > > Do we want try to get this separation done after the current
> > > > release
> > > > > > > cycle
> > > > > > > > is over?
> > > > > > > > If we do, do we have a preferred layout? I didn't see
> anything
> > > > Apache
> > > > > > > > preferred in a quick search, but I definitely could have
> missed
> > > > > > something
> > > > > > > > (and https://checker.apache.org/projs/nifi.html looks clean
> > for
> > > > > NiFi,
> > > > > > > so I
> > > > > > > > assume it's fine.)
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > --
> > >
> > > Jon
> > >
> >
>
--
Jon
Re: [DISCUSS] Split apart releases for core Metron and the Bro plugin
Posted by Justin Leet <ju...@gmail.com>.
https://github.com/apache/metron/pull/1188 scripts the creation of RC's.
It does this split, and allows for independent releases. The main catch is
a slight hangup with the KEYS file.
The metron-bro-kafka-plugin repo doesn't contain a KEYS file, it currently
has just been aligned with the main repo's KEYS file.The KEYS file doesn't
need to live in each submodule's directory, just in the main folder (
https://dist.apache.org/repos/dist/release/metron/). This means it's not a
problem for the plugin repo to be missing it.
The main catch is that right now, we only publish the KEYS file when we
release the main repo. In the (admittedly rare) situation where we have a
new release manager who has to update the KEYS file, we'd currently need to
do a metron release before we could do a plugin release.
Should we split out and document a KEYS update from the main repo?
Essentially, just run through the normal PR process and then have a post
merge step of kicking up the updated KEYS file. Then Release Process
<https://cwiki.apache.org/confluence/display/METRON/Release+Process> would
just get updated to reflect this process.
On Fri, Sep 7, 2018 at 3:15 PM Casey Stella <ce...@gmail.com> wrote:
> +1 to defer for this release and complete separation. Good fences make
> good submodules. ;)
>
> On Fri, Sep 7, 2018 at 2:33 PM Zeolla@GMail.com <ze...@gmail.com> wrote:
>
> > +1 to defer for this release and +1 to Justin's suggested release/dist
> > directory breakout and complete separation.
> >
> > Jon
> >
> > On Fri, Sep 7, 2018 at 1:43 PM Michael Miklavcic <
> > michael.miklavcic@gmail.com> wrote:
> >
> > > +1 to deferring for this release and having the separation like NiFi.
> > Since
> > > we're bootstrapping from their process, what are they doing? I would
> > assume
> > > we'd want some sort of vote for the plugin version change as well.
> > >
> > > On Fri, Sep 7, 2018 at 10:15 AM Nick Allen <ni...@nickallen.org> wrote:
> > >
> > > > +1 for complete separation as you've described.
> > > >
> > > > On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <ju...@gmail.com>
> > > wrote:
> > > >
> > > > > I would like this to be a complete separation. Complete with
> > separate
> > > > RCs,
> > > > > separate call to vote, etc. There's a bit more overhead, but plugin
> > > > > releases should be rarer and as the release infra gets improved and
> > > > > scripted out more, I don't think it'll end up being much more than
> > > > bundling
> > > > > it together.
> > > > >
> > > > > On Fri, Sep 7, 2018 at 11:27 AM Nick Allen <ni...@nickallen.org>
> > wrote:
> > > > >
> > > > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>,
> split
> > > > apart
> > > > > > these releases within their dist directories.
> > > > > >
> > > > > > I prefer the way Nifi organizes it. Definitely seems more
> > logically
> > > > > > organized.
> > > > > >
> > > > > >
> > > > > > > If we split them apart, we can make the releases independently.
> > > This
> > > > > > fixes the problem of aligning the versions (simply release the
> > plugin
> > > > > > first, update full-dev, release core Metron).
> > > > > >
> > > > > > Does this entail a complete separation; including a separate
> > > > > call-to-vote?
> > > > > > One vote for core Metron and a separate vote for plugin?
> > > > > >
> > > > > >
> > > > > > > Do we want try to get this separation done after the current
> > > release
> > > > > > cycle is over?
> > > > > >
> > > > > > +1 Let's wait for the next release to hash this out.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <
> justinjleet@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > Right now, we tie together our main release and the Bro plugin,
> > as
> > > > seen
> > > > > > in
> > > > > > > our 0.4.2 release
> > > > > > > https://archive.apache.org/dist/metron/0.4.2/ and the current
> > RC.
> > > > > > >
> > > > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>,
> split
> > > > apart
> > > > > > > these
> > > > > > > releases within their dist directories.
> > > > > > >
> > > > > > > In our case this might look something like
> > > > > > > 0.5.0/
> > > > > > > metron-bro-plugin-kafka
> > > > > > > - 0.2.0/
> > > > > > >
> > > > > > > Right now, with the releases tied together, we aren't upgrading
> > > > > full-dev
> > > > > > > with the version of the plugin (because we're releasing
> > > > simultaneously
> > > > > > and
> > > > > > > can't update the version number).
> > > > > > >
> > > > > > > If we split them apart, we can make the releases independently.
> > > This
> > > > > > fixes
> > > > > > > the problem of aligning the versions (simply release the plugin
> > > > first,
> > > > > > > update full-dev, release core Metron). The plugin also updates
> > > > > > > substantially less often and we can just do those releases at a
> > > > cadence
> > > > > > we
> > > > > > > choose.
> > > > > > >
> > > > > > > Any thoughts on doing this?
> > > > > > > Do we want try to get this separation done after the current
> > > release
> > > > > > cycle
> > > > > > > is over?
> > > > > > > If we do, do we have a preferred layout? I didn't see anything
> > > Apache
> > > > > > > preferred in a quick search, but I definitely could have missed
> > > > > something
> > > > > > > (and https://checker.apache.org/projs/nifi.html looks clean
> for
> > > > NiFi,
> > > > > > so I
> > > > > > > assume it's fine.)
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > --
> >
> > Jon
> >
>
Re: [DISCUSS] Split apart releases for core Metron and the Bro plugin
Posted by Casey Stella <ce...@gmail.com>.
+1 to defer for this release and complete separation. Good fences make
good submodules. ;)
On Fri, Sep 7, 2018 at 2:33 PM Zeolla@GMail.com <ze...@gmail.com> wrote:
> +1 to defer for this release and +1 to Justin's suggested release/dist
> directory breakout and complete separation.
>
> Jon
>
> On Fri, Sep 7, 2018 at 1:43 PM Michael Miklavcic <
> michael.miklavcic@gmail.com> wrote:
>
> > +1 to deferring for this release and having the separation like NiFi.
> Since
> > we're bootstrapping from their process, what are they doing? I would
> assume
> > we'd want some sort of vote for the plugin version change as well.
> >
> > On Fri, Sep 7, 2018 at 10:15 AM Nick Allen <ni...@nickallen.org> wrote:
> >
> > > +1 for complete separation as you've described.
> > >
> > > On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <ju...@gmail.com>
> > wrote:
> > >
> > > > I would like this to be a complete separation. Complete with
> separate
> > > RCs,
> > > > separate call to vote, etc. There's a bit more overhead, but plugin
> > > > releases should be rarer and as the release infra gets improved and
> > > > scripted out more, I don't think it'll end up being much more than
> > > bundling
> > > > it together.
> > > >
> > > > On Fri, Sep 7, 2018 at 11:27 AM Nick Allen <ni...@nickallen.org>
> wrote:
> > > >
> > > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split
> > > apart
> > > > > these releases within their dist directories.
> > > > >
> > > > > I prefer the way Nifi organizes it. Definitely seems more
> logically
> > > > > organized.
> > > > >
> > > > >
> > > > > > If we split them apart, we can make the releases independently.
> > This
> > > > > fixes the problem of aligning the versions (simply release the
> plugin
> > > > > first, update full-dev, release core Metron).
> > > > >
> > > > > Does this entail a complete separation; including a separate
> > > > call-to-vote?
> > > > > One vote for core Metron and a separate vote for plugin?
> > > > >
> > > > >
> > > > > > Do we want try to get this separation done after the current
> > release
> > > > > cycle is over?
> > > > >
> > > > > +1 Let's wait for the next release to hash this out.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <justinjleet@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > Right now, we tie together our main release and the Bro plugin,
> as
> > > seen
> > > > > in
> > > > > > our 0.4.2 release
> > > > > > https://archive.apache.org/dist/metron/0.4.2/ and the current
> RC.
> > > > > >
> > > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split
> > > apart
> > > > > > these
> > > > > > releases within their dist directories.
> > > > > >
> > > > > > In our case this might look something like
> > > > > > 0.5.0/
> > > > > > metron-bro-plugin-kafka
> > > > > > - 0.2.0/
> > > > > >
> > > > > > Right now, with the releases tied together, we aren't upgrading
> > > > full-dev
> > > > > > with the version of the plugin (because we're releasing
> > > simultaneously
> > > > > and
> > > > > > can't update the version number).
> > > > > >
> > > > > > If we split them apart, we can make the releases independently.
> > This
> > > > > fixes
> > > > > > the problem of aligning the versions (simply release the plugin
> > > first,
> > > > > > update full-dev, release core Metron). The plugin also updates
> > > > > > substantially less often and we can just do those releases at a
> > > cadence
> > > > > we
> > > > > > choose.
> > > > > >
> > > > > > Any thoughts on doing this?
> > > > > > Do we want try to get this separation done after the current
> > release
> > > > > cycle
> > > > > > is over?
> > > > > > If we do, do we have a preferred layout? I didn't see anything
> > Apache
> > > > > > preferred in a quick search, but I definitely could have missed
> > > > something
> > > > > > (and https://checker.apache.org/projs/nifi.html looks clean for
> > > NiFi,
> > > > > so I
> > > > > > assume it's fine.)
> > > > > >
> > > > >
> > > >
> > >
> >
> --
>
> Jon
>
Re: [DISCUSS] Split apart releases for core Metron and the Bro plugin
Posted by "Zeolla@GMail.com" <ze...@gmail.com>.
+1 to defer for this release and +1 to Justin's suggested release/dist
directory breakout and complete separation.
Jon
On Fri, Sep 7, 2018 at 1:43 PM Michael Miklavcic <
michael.miklavcic@gmail.com> wrote:
> +1 to deferring for this release and having the separation like NiFi. Since
> we're bootstrapping from their process, what are they doing? I would assume
> we'd want some sort of vote for the plugin version change as well.
>
> On Fri, Sep 7, 2018 at 10:15 AM Nick Allen <ni...@nickallen.org> wrote:
>
> > +1 for complete separation as you've described.
> >
> > On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <ju...@gmail.com>
> wrote:
> >
> > > I would like this to be a complete separation. Complete with separate
> > RCs,
> > > separate call to vote, etc. There's a bit more overhead, but plugin
> > > releases should be rarer and as the release infra gets improved and
> > > scripted out more, I don't think it'll end up being much more than
> > bundling
> > > it together.
> > >
> > > On Fri, Sep 7, 2018 at 11:27 AM Nick Allen <ni...@nickallen.org> wrote:
> > >
> > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split
> > apart
> > > > these releases within their dist directories.
> > > >
> > > > I prefer the way Nifi organizes it. Definitely seems more logically
> > > > organized.
> > > >
> > > >
> > > > > If we split them apart, we can make the releases independently.
> This
> > > > fixes the problem of aligning the versions (simply release the plugin
> > > > first, update full-dev, release core Metron).
> > > >
> > > > Does this entail a complete separation; including a separate
> > > call-to-vote?
> > > > One vote for core Metron and a separate vote for plugin?
> > > >
> > > >
> > > > > Do we want try to get this separation done after the current
> release
> > > > cycle is over?
> > > >
> > > > +1 Let's wait for the next release to hash this out.
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <ju...@gmail.com>
> > > wrote:
> > > >
> > > > > Right now, we tie together our main release and the Bro plugin, as
> > seen
> > > > in
> > > > > our 0.4.2 release
> > > > > https://archive.apache.org/dist/metron/0.4.2/ and the current RC.
> > > > >
> > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split
> > apart
> > > > > these
> > > > > releases within their dist directories.
> > > > >
> > > > > In our case this might look something like
> > > > > 0.5.0/
> > > > > metron-bro-plugin-kafka
> > > > > - 0.2.0/
> > > > >
> > > > > Right now, with the releases tied together, we aren't upgrading
> > > full-dev
> > > > > with the version of the plugin (because we're releasing
> > simultaneously
> > > > and
> > > > > can't update the version number).
> > > > >
> > > > > If we split them apart, we can make the releases independently.
> This
> > > > fixes
> > > > > the problem of aligning the versions (simply release the plugin
> > first,
> > > > > update full-dev, release core Metron). The plugin also updates
> > > > > substantially less often and we can just do those releases at a
> > cadence
> > > > we
> > > > > choose.
> > > > >
> > > > > Any thoughts on doing this?
> > > > > Do we want try to get this separation done after the current
> release
> > > > cycle
> > > > > is over?
> > > > > If we do, do we have a preferred layout? I didn't see anything
> Apache
> > > > > preferred in a quick search, but I definitely could have missed
> > > something
> > > > > (and https://checker.apache.org/projs/nifi.html looks clean for
> > NiFi,
> > > > so I
> > > > > assume it's fine.)
> > > > >
> > > >
> > >
> >
>
--
Jon
Re: [DISCUSS] Split apart releases for core Metron and the Bro plugin
Posted by Michael Miklavcic <mi...@gmail.com>.
+1 to deferring for this release and having the separation like NiFi. Since
we're bootstrapping from their process, what are they doing? I would assume
we'd want some sort of vote for the plugin version change as well.
On Fri, Sep 7, 2018 at 10:15 AM Nick Allen <ni...@nickallen.org> wrote:
> +1 for complete separation as you've described.
>
> On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <ju...@gmail.com> wrote:
>
> > I would like this to be a complete separation. Complete with separate
> RCs,
> > separate call to vote, etc. There's a bit more overhead, but plugin
> > releases should be rarer and as the release infra gets improved and
> > scripted out more, I don't think it'll end up being much more than
> bundling
> > it together.
> >
> > On Fri, Sep 7, 2018 at 11:27 AM Nick Allen <ni...@nickallen.org> wrote:
> >
> > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split
> apart
> > > these releases within their dist directories.
> > >
> > > I prefer the way Nifi organizes it. Definitely seems more logically
> > > organized.
> > >
> > >
> > > > If we split them apart, we can make the releases independently. This
> > > fixes the problem of aligning the versions (simply release the plugin
> > > first, update full-dev, release core Metron).
> > >
> > > Does this entail a complete separation; including a separate
> > call-to-vote?
> > > One vote for core Metron and a separate vote for plugin?
> > >
> > >
> > > > Do we want try to get this separation done after the current release
> > > cycle is over?
> > >
> > > +1 Let's wait for the next release to hash this out.
> > >
> > >
> > >
> > >
> > > On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <ju...@gmail.com>
> > wrote:
> > >
> > > > Right now, we tie together our main release and the Bro plugin, as
> seen
> > > in
> > > > our 0.4.2 release
> > > > https://archive.apache.org/dist/metron/0.4.2/ and the current RC.
> > > >
> > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split
> apart
> > > > these
> > > > releases within their dist directories.
> > > >
> > > > In our case this might look something like
> > > > 0.5.0/
> > > > metron-bro-plugin-kafka
> > > > - 0.2.0/
> > > >
> > > > Right now, with the releases tied together, we aren't upgrading
> > full-dev
> > > > with the version of the plugin (because we're releasing
> simultaneously
> > > and
> > > > can't update the version number).
> > > >
> > > > If we split them apart, we can make the releases independently. This
> > > fixes
> > > > the problem of aligning the versions (simply release the plugin
> first,
> > > > update full-dev, release core Metron). The plugin also updates
> > > > substantially less often and we can just do those releases at a
> cadence
> > > we
> > > > choose.
> > > >
> > > > Any thoughts on doing this?
> > > > Do we want try to get this separation done after the current release
> > > cycle
> > > > is over?
> > > > If we do, do we have a preferred layout? I didn't see anything Apache
> > > > preferred in a quick search, but I definitely could have missed
> > something
> > > > (and https://checker.apache.org/projs/nifi.html looks clean for
> NiFi,
> > > so I
> > > > assume it's fine.)
> > > >
> > >
> >
>
Re: [DISCUSS] Split apart releases for core Metron and the Bro plugin
Posted by Nick Allen <ni...@nickallen.org>.
+1 for complete separation as you've described.
On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <ju...@gmail.com> wrote:
> I would like this to be a complete separation. Complete with separate RCs,
> separate call to vote, etc. There's a bit more overhead, but plugin
> releases should be rarer and as the release infra gets improved and
> scripted out more, I don't think it'll end up being much more than bundling
> it together.
>
> On Fri, Sep 7, 2018 at 11:27 AM Nick Allen <ni...@nickallen.org> wrote:
>
> > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split apart
> > these releases within their dist directories.
> >
> > I prefer the way Nifi organizes it. Definitely seems more logically
> > organized.
> >
> >
> > > If we split them apart, we can make the releases independently. This
> > fixes the problem of aligning the versions (simply release the plugin
> > first, update full-dev, release core Metron).
> >
> > Does this entail a complete separation; including a separate
> call-to-vote?
> > One vote for core Metron and a separate vote for plugin?
> >
> >
> > > Do we want try to get this separation done after the current release
> > cycle is over?
> >
> > +1 Let's wait for the next release to hash this out.
> >
> >
> >
> >
> > On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <ju...@gmail.com>
> wrote:
> >
> > > Right now, we tie together our main release and the Bro plugin, as seen
> > in
> > > our 0.4.2 release
> > > https://archive.apache.org/dist/metron/0.4.2/ and the current RC.
> > >
> > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split apart
> > > these
> > > releases within their dist directories.
> > >
> > > In our case this might look something like
> > > 0.5.0/
> > > metron-bro-plugin-kafka
> > > - 0.2.0/
> > >
> > > Right now, with the releases tied together, we aren't upgrading
> full-dev
> > > with the version of the plugin (because we're releasing simultaneously
> > and
> > > can't update the version number).
> > >
> > > If we split them apart, we can make the releases independently. This
> > fixes
> > > the problem of aligning the versions (simply release the plugin first,
> > > update full-dev, release core Metron). The plugin also updates
> > > substantially less often and we can just do those releases at a cadence
> > we
> > > choose.
> > >
> > > Any thoughts on doing this?
> > > Do we want try to get this separation done after the current release
> > cycle
> > > is over?
> > > If we do, do we have a preferred layout? I didn't see anything Apache
> > > preferred in a quick search, but I definitely could have missed
> something
> > > (and https://checker.apache.org/projs/nifi.html looks clean for NiFi,
> > so I
> > > assume it's fine.)
> > >
> >
>
Re: [DISCUSS] Split apart releases for core Metron and the Bro plugin
Posted by Justin Leet <ju...@gmail.com>.
I would like this to be a complete separation. Complete with separate RCs,
separate call to vote, etc. There's a bit more overhead, but plugin
releases should be rarer and as the release infra gets improved and
scripted out more, I don't think it'll end up being much more than bundling
it together.
On Fri, Sep 7, 2018 at 11:27 AM Nick Allen <ni...@nickallen.org> wrote:
> > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split apart
> these releases within their dist directories.
>
> I prefer the way Nifi organizes it. Definitely seems more logically
> organized.
>
>
> > If we split them apart, we can make the releases independently. This
> fixes the problem of aligning the versions (simply release the plugin
> first, update full-dev, release core Metron).
>
> Does this entail a complete separation; including a separate call-to-vote?
> One vote for core Metron and a separate vote for plugin?
>
>
> > Do we want try to get this separation done after the current release
> cycle is over?
>
> +1 Let's wait for the next release to hash this out.
>
>
>
>
> On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <ju...@gmail.com> wrote:
>
> > Right now, we tie together our main release and the Bro plugin, as seen
> in
> > our 0.4.2 release
> > https://archive.apache.org/dist/metron/0.4.2/ and the current RC.
> >
> > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split apart
> > these
> > releases within their dist directories.
> >
> > In our case this might look something like
> > 0.5.0/
> > metron-bro-plugin-kafka
> > - 0.2.0/
> >
> > Right now, with the releases tied together, we aren't upgrading full-dev
> > with the version of the plugin (because we're releasing simultaneously
> and
> > can't update the version number).
> >
> > If we split them apart, we can make the releases independently. This
> fixes
> > the problem of aligning the versions (simply release the plugin first,
> > update full-dev, release core Metron). The plugin also updates
> > substantially less often and we can just do those releases at a cadence
> we
> > choose.
> >
> > Any thoughts on doing this?
> > Do we want try to get this separation done after the current release
> cycle
> > is over?
> > If we do, do we have a preferred layout? I didn't see anything Apache
> > preferred in a quick search, but I definitely could have missed something
> > (and https://checker.apache.org/projs/nifi.html looks clean for NiFi,
> so I
> > assume it's fine.)
> >
>
Re: [DISCUSS] Split apart releases for core Metron and the Bro plugin
Posted by Nick Allen <ni...@nickallen.org>.
> Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split apart
these releases within their dist directories.
I prefer the way Nifi organizes it. Definitely seems more logically
organized.
> If we split them apart, we can make the releases independently. This
fixes the problem of aligning the versions (simply release the plugin
first, update full-dev, release core Metron).
Does this entail a complete separation; including a separate call-to-vote?
One vote for core Metron and a separate vote for plugin?
> Do we want try to get this separation done after the current release
cycle is over?
+1 Let's wait for the next release to hash this out.
On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <ju...@gmail.com> wrote:
> Right now, we tie together our main release and the Bro plugin, as seen in
> our 0.4.2 release
> https://archive.apache.org/dist/metron/0.4.2/ and the current RC.
>
> Other projects, e.g. NiFi <http://apache.org/dist/nifi/>, split apart
> these
> releases within their dist directories.
>
> In our case this might look something like
> 0.5.0/
> metron-bro-plugin-kafka
> - 0.2.0/
>
> Right now, with the releases tied together, we aren't upgrading full-dev
> with the version of the plugin (because we're releasing simultaneously and
> can't update the version number).
>
> If we split them apart, we can make the releases independently. This fixes
> the problem of aligning the versions (simply release the plugin first,
> update full-dev, release core Metron). The plugin also updates
> substantially less often and we can just do those releases at a cadence we
> choose.
>
> Any thoughts on doing this?
> Do we want try to get this separation done after the current release cycle
> is over?
> If we do, do we have a preferred layout? I didn't see anything Apache
> preferred in a quick search, but I definitely could have missed something
> (and https://checker.apache.org/projs/nifi.html looks clean for NiFi, so I
> assume it's fine.)
>