The question is if we actually need to back-port at all at this point. I think the assertion here is that pretty much everyone using Metron right now is currently getting patches, etc. by upgrading to the latest release. If/when we find a need to fork release branches we can certainly do it and have a more involved discussion pertinent to the circumstances at hand.
On Tue, Nov 15, 2016 at 10:17 AM, Otto Fowler <[email protected]> wrote: > Would the back ports also have to go through a full ‘apache release’ > process and be planned out as well? > I don’t think that should all be worked out as we go. > > > On November 15, 2016 at 12:13:55, Michael Miklavcic ( > [email protected]) wrote: > > I'm a +1 on David and Nick's suggestions. 1 and 2 now, and let 3 happen > organically when the community has a need. > > On Tue, Nov 15, 2016 at 9:29 AM, David Lyle <[email protected]> wrote: > > > I think that's an excellent understanding and suggestion on #3. > > > > Fwiw, the norm I've seen is to allow the requester and the dev to work > that > > out. > > > > Thanks, > > > > -D... > > > > > > On Tue, Nov 15, 2016 at 11:22 AM, Nick Allen <[email protected]> > wrote: > > > > > I broke down what I am understanding of your suggestion into bullet > > > points. Please correct me if I am wrong. > > > > > > (1) Bump the rev immediately following a release > > > (2) Update the current version in master to 0.4.0 > > > (3) Maintain and back port bug fixes to a 0.3.x branch > > > > > > > > > I would agree with you on items (1) and (2); +1 on those. > > > > > > Item (3) is what drove my questions. I feel this needs a little more > > > discussion to outline what gets back ported, how it is back ported and > > when > > > that might occur. I am not concerned about the technicalities of > > > maintaining multiple branches, more the process side of things. > > > > > > Maybe we could sit on (3) until there is a community member with an > > > interest in back porting a fix? Right now, I don't know of any, but > maybe > > > I've missed a conversation. > > > > > > > > > > > > > > > > > > On Tue, Nov 15, 2016 at 10:42 AM, David Lyle <[email protected]> > > wrote: > > > > > > > So, the notion is- we're going to have a 0.4.0 release at some > future > > > > point. If, during that release cycle, we found critical bug fix type > > > issues > > > > that we wanted to release out of cycle, we could patch the 0.3.0 > branch > > > and > > > > cut a release from there. You're correct that we'd have to commit > them > > to > > > > both branches. I don't know of a way to avoid that with that type of > > > stuff, > > > > so I think the best we can do is to minimize them. > > > > > > > > Alternatively, we can decide that the next release will be 0.3.1 and > > > either > > > > abandon the notion of semantic versioning [1] (i.e. put features and > > bug > > > > fixes in a x.x.1 release) or only release bug fixes. > > > > > > > > I don't really have a strong preference excepting that I know for > sure > > > that > > > > master will no longer be 0.3.0 once 0.3.0 is released, so we should > > bump > > > > the rev immediately following the 0.3.0 release (if not sooner). > > > > > > > > -D... > > > > > > > > [1] http://semver.org/ > > > > > > > > > > > > On Tue, Nov 15, 2016 at 9:52 AM, Nick Allen <[email protected]> > > wrote: > > > > > > > > > What kind of PRs would qualify as 0.3.x fixes? How would we decide > > > that? > > > > > For those we would then have to commit them against both the 0.3.x > > > branch > > > > > and master (0.4.0), right? > > > > > > > > > > Off the top of your head, can you think of a few recent PRs that > > would > > > > > qualify as patches? I'd just like to get a feel for how many of > > those > > > > > might exist. > > > > > > > > > > > > > > > > > > > > On Mon, Nov 14, 2016 at 6:58 PM, David Lyle <[email protected]> > > > > > wrote: > > > > > > > > > > > Hi Mike, > > > > > > > > > > > > I'd like to see us increment the version on master ASAP. Once > 0.3.0 > > > is > > > > > > released, master is no longer the 0.3.0 branch. > > > > > > > > > > > > I recommend that we run 0.3.x patches off the 0.3.0 release > branch > > > and > > > > > > rename master to 0.4.0. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -D... > > > > > > > > > > > > > > > > > > On Mon, Nov 14, 2016 at 4:40 PM, Michael Miklavcic < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > 1 - What the next version should be. > > > > > > > 2 - When we should increment the version > > > > > > > > > > > > > > On Mon, Nov 14, 2016 at 2:35 PM, [email protected] < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > Sorry, but I don't exactly follow. Are you looking to > discuss > > > what > > > > > the > > > > > > > > version number should be next time around (1.0 vs 0.4 vs > > 0.3.1?) > > > or > > > > > > what > > > > > > > > tasks need to be accomplished before the next version of > metron > > > is > > > > > > > > considered ready? Thanks, > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > On Mon, Nov 14, 2016, 16:29 Michael Miklavcic < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > This is a thread to discuss what the next version of > Metron > > > > should > > > > > be > > > > > > > > > after Apache > > > > > > > > > Metron 0.3.0-RC1 incubating is released, e.g. 0.3.1? > > > > > > > > > > > > > > > > > > I'd like to up the rev asap, however one thing to consider > is > > > > that > > > > > we > > > > > > > > might > > > > > > > > > change the version again at a later point in time prior to > > the > > > > next > > > > > > > > > release. This current release candidate being a case in > > point. > > > On > > > > > the > > > > > > > > other > > > > > > > > > hand, I am also currently working on simplifying the > version > > > > change > > > > > > > > process > > > > > > > > > so it might not be a big deal either way. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Mike Miklavcic > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > Sent from my mobile device > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Nick Allen <[email protected]> > > > > > > > > > > > > > > > > > > > > > -- > > > Nick Allen <[email protected]> > > > > > > >
