+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 <n...@nickallen.org> wrote: > +1 for complete separation as you've described. > > On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <justinjl...@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 <n...@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 <justinjl...@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.) > > > > > > > > > >
