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