On 05/31/2012 12:35 AM, Kevin Kluge wrote:
The master branch hasn't diverged much from the 3.0.x branch at this point.  I 
can't name any divergence off the top of my head.  I would expect 3.0.x to be 
more stable, but if there is another reason to go forth with master then I 
wouldn't stop that for stability reasons.

New features going to master for 4.1.x  (though our focus should really be on
getting an ASF-acceptable release out) Rename the 3.0.x branch to 4.0.x to
reflect reality.

Renaming the branch will create confusion.  The previous 3.0.x releases have 
already been done off of it so all the committers (and anyone else that has 
been looking at the code) are expecting this to be the 3.0.x release set.  We 
could plausibly cut a 4.0.0 and future 4.0.x releases off the 3.0.x branch.  
That is a little odd but (IMO) less confusing than renaming the branch out from 
under people.

We could also take a 4.0.x branch off 3.0.x or master.   That leaves open the 
option of a later 3.0.x release on the 3.0.x branch.  That seems the cleanest 
approach to me, but it would add some additional branch management overhead if 
fixes are needed in both 3.0.x and 4.0.x.

I might have a slight preference to branching 4.0.x off master.  Then we would 
establish a pattern that major releases get branched from master, as was done 
for 3.0.0 and 4.0.0.   This would extend naturally into 5.0.0, etc.  and is 
easy to explain to new committers.

I fully agree with Kevin. Branching 4.0.x off 3.0.x instead of master is confusing. We should always branch major release branches off master. This does not mean we have to branch 4.0.x of HEAD in master, we can choose an earlier commit in master if there is concern that HEAD has some instabilities.

My $0.02
Robert


--
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rjsch...@suse.com
rschw...@ca.ibm.com
781-464-8147

Reply via email to