might make more sense to create a 2.6.1 branch from the 2.6.0 release tag and cherry pick all of the relevant commits in. leave master as pointing to 2.7.0. if you have both branches active at once then commit to master and continue to cherry-pick as appropriate. or commit to the branch and merge to master, that one is probably easier for committers but harder for contributors so i'd advise against it. then, when you release 2.6.1, just kill the branch, and if you decide to do a 2.6.2 then create a new one at that point.
On Mon, Jul 28, 2014 at 4:43 PM, Jordan Zimmerman < [email protected]> wrote: > That’s a good point. I think, we’d have master just be whatever the next > release will be. Then, we could have a 2.7.0 branch that would become > master after 2.6.1 is released. OK? > > -JZ > > From: Cameron McKenzie <[email protected]> > Reply: [email protected] <[email protected]>> > Date: July 28, 2014 at 4:42:57 PM > To: [email protected] <[email protected]>> > Subject: Re: FYI - changing 2.6.1 to 2.7.0 > > How would we manage this with our current branching structure? > > > On Tue, Jul 29, 2014 at 7:36 AM, Mike Drob <[email protected]> wrote: > > > Is it possible (or desirable?) to split some of the bug fixes into a > 2.6.1 > > before adding the APIs for 2.7.0? > > > > > > On Mon, Jul 28, 2014 at 4:34 PM, Jordan Zimmerman < > > [email protected]> wrote: > > > > > FYI > > > > > > There will be some new APIs in the next release (CURATOR-126 for > example) > > > that suggests making this 2.7.0 instead of 2.6.1 > > > > > > -JZ > > > > > > > > >
