Hi,
On 06/01/2012 04:37 PM, Robert Schweikert wrote:
On 05/31/2012 01:35 PM, David Nalley wrote:
On Thu, May 31, 2012 at 8:15 AM, Robert Schweikert<rjsch...@suse.com>
wrote:
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
OK - I can see the logic in that. Soooo - do we need the 3.0.x branch
around anymore? Or perhaps better put - do we intend to use it - even
if we don't purge it?
Well, that's kind off a Citrix question. Is Citrix interested in having
a public branch to work in? From a community perspective it woudl appear
that only the master branch is of interest plus any feature branches
that are public.
I don't get the Citrix question? CloudStack is switching to an Apache
project.
If some people inside Citrix want to work in their own private
repository that's fine, but there will be no "special" Citrix branch of
CloudStack?
A couple of follow on questions - when should we
branch master to build 4.0.x?
I am generally in favor of a "branch as late as possible" model to avoid
duplicate work (2 commits). However there are also good reasons to
"branch early" as this model tends to have less impact on new feature
development. For the first go around, intended mostly for "clean up
tasks" the branch timing is probably less important.
I agree with the "branch as late as possible". I'd say stick with the
master branch for all the relevant work and build new features in their
down branch.
When those features are ready you merge them into the master and tag the
master to v4.0.0
I personally don't like working in multiple branches as merging them
back again is not that easy, they can diverge to much from each other.
Wido
Later,
Robert
