> 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.) >
