You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2014/07/28 23:34:18 UTC

FYI - changing 2.6.1 to 2.7.0

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

Re: FYI - changing 2.6.1 to 2.7.0

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I’m not a fan of cherry picking, etc. I’ve seen too many mistakes made. Officially, Curator follows Github Flow: http://scottchacon.com/2011/08/31/github-flow.html - which boils down to have a master and lots of other branches. So, maybe even having a 2.7.0 branch would be a mistake. Features ready to be released are in master and everything else is just waiting in its branch.

-Jordan

From: Mike Drob <ma...@cloudera.com>
Reply: dev@curator.apache.org <de...@curator.apache.org>>
Date: July 28, 2014 at 4:49:56 PM
To: dev@curator.apache.org <de...@curator.apache.org>>
Cc: Cameron McKenzie <mc...@gmail.com>>
Subject:  Re: FYI - changing 2.6.1 to 2.7.0  

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 <  
jordan@jordanzimmerman.com> 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 <mc...@gmail.com>  
> Reply: dev@curator.apache.org <de...@curator.apache.org>>  
> Date: July 28, 2014 at 4:42:57 PM  
> To: dev@curator.apache.org <de...@curator.apache.org>>  
> 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 <ma...@cloudera.com> 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 <  
> > jordan@jordanzimmerman.com> 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  
> > >  
> > >  
> >  
>

Re: FYI - changing 2.6.1 to 2.7.0

Posted by Mike Drob <ma...@cloudera.com>.
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 <
jordan@jordanzimmerman.com> 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 <mc...@gmail.com>
> Reply: dev@curator.apache.org <de...@curator.apache.org>>
> Date: July 28, 2014 at 4:42:57 PM
> To: dev@curator.apache.org <de...@curator.apache.org>>
> 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 <ma...@cloudera.com> 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 <
> > jordan@jordanzimmerman.com> 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
> > >
> > >
> >
>

Re: FYI - changing 2.6.1 to 2.7.0

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <mc...@gmail.com>
Reply: dev@curator.apache.org <de...@curator.apache.org>>
Date: July 28, 2014 at 4:42:57 PM
To: dev@curator.apache.org <de...@curator.apache.org>>
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 <ma...@cloudera.com> 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 <  
> jordan@jordanzimmerman.com> 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  
> >  
> >  
>

Re: FYI - changing 2.6.1 to 2.7.0

Posted by Cameron McKenzie <mc...@gmail.com>.
How would we manage this with our current branching structure?


On Tue, Jul 29, 2014 at 7:36 AM, Mike Drob <ma...@cloudera.com> 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 <
> jordan@jordanzimmerman.com> 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
> >
> >
>

Re: FYI - changing 2.6.1 to 2.7.0

Posted by Mike Drob <ma...@cloudera.com>.
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 <
jordan@jordanzimmerman.com> 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
>
>