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 <[email protected]> wrote: > +1 to defer for this release and complete separation. Good fences make > good submodules. ;) > > On Fri, Sep 7, 2018 at 2:33 PM [email protected] <[email protected]> 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 < > > [email protected]> 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 <[email protected]> wrote: > > > > > > > +1 for complete separation as you've described. > > > > > > > > On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <[email protected]> > > > 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 <[email protected]> > > 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 < > [email protected] > > > > > > > > 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 > > >
