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]> > > >
