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