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 <justinjl...@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 <ceste...@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 zeo...@gmail.com <zeo...@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.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 > > > > > > -- Jon
