+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.miklav...@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 <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.) > > > > > > > > > > > > > > > -- Jon
