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 <n...@nickallen.org> 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 <dlyle65...@gmail.com> 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 < > > michael.miklav...@gmail.com> wrote: > > > > > 1 - What the next version should be. > > > 2 - When we should increment the version > > > > > > On Mon, Nov 14, 2016 at 2:35 PM, zeo...@gmail.com <zeo...@gmail.com> > > > 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 < > > > michael.miklav...@gmail.com > > > > > > > > > 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 <n...@nickallen.org> >
