On Jul 31, 2014, at 12:55 AM, Sheng Yang <sh...@yasker.org> wrote:
> I suppose it would work like this:
> 1. In the original model, every release branch would be deleted after merge
> into develop and master branch. There is no release/4.4.1 or release/4.5
> branch.
> 2. Say we don't follow original model, when one release is released, you
> keep it. Say we have release/4.4 and release/4.5. And currently we're
> working on 4.7 which is develop branch, MASTER is 4.6.
> 3. I have one bug in 4.4, I checked in a fix in 4.4. Release 4.4.1.
> 4. Then, conflict would happen when you merge release/4.4. branch to
> release/4.5. Since the version number changed to 4.4.1. You need to deal
> with version number conflict every time when merge to upper release.
> 5. Suppose you dealt with version number change. New release/4.5 would
> merge release/4.4 which merged release/4.3. Then you want to merge to
> master because there is a fix. Well, dealt with version number change
> conflict again.
> 6. Then, you would need to merge master to develop branch?
>
> I am little worry about the conflict every time when merge happened. Seems
> version number conflict need to be dealt with everytime, and probably some
> other conflict. The conflict need to be solved may result in more
> error-prone situation.
Well, yes, _that_ would be horrible! :-)
Fortunately a merge only considers things that haven’t been merged before. If V
means ‘bump version’, given
master -----------------------------------------
\ / \
r/4.5 V1---y----------V2 \
\ \
r/4.6 \ V3--z-----------
\ /
fix x---------------
because V1 is an ancestor of V3, when you merge x into r/4.6, git knows not to
consider V1 commit again. It knows it only has to consider x. There is no
conflict due to V1 or V2 at z. If you would do this
master ------------------------------------------
\ \ /
r/4.5 V1-----\-V2----------------------------
\ \ \
r/4.6 V3---\-----z——-\----------z2--
\ / \ /
fix x—- \ /
\ /
fix2 x2--
you will have a merge conflict once, at spot z, where you will have to resolve
the conflict created by having conflicting ancestors V2 and V3. But you won’t
have to deal with it at spot z2, since git will remember you already resolved
that conflict before.
As long as you merge, instead of cherry-pick.
>> For example, the linux kernel has at least two active minor releases at
>> any given time, and many more minor releases and forks going on at that
>> same time, with hundreds (thousands?) of active developers, and even _they_
>> don’t need freezes. Instead the power is in their choices of what they do
>> and do not
>
> I've worked on Linux kernel for years,
If you have experience with linux’ approach, I’d suggest you just look at
git-flow as a massively simplified version of roughly that, which is easier to
get into, something to hold on to while you develop experience and then good
judgement [1] of when/what/where to merge. A reasonable starting point. Also,
now I _really_ don’t understand why we have to have this discussion :)
> they do have an strict code freeze.
Well, sure, but the linux freeze is a very _different_ kind of code freeze to
what cloudstack has been doing :). All that happens is the maintainers decide
to stop merging things into their RC branches. The wider linux community
doesn’t skip a beat. Heck, IMHO, if cloudstack were to adopt a more linux-like
model that would be awesome…but you have to walk before you can run…for some
reason I suspect this community is not ready to start rejecting commits because
the first line of their message overruns 72 characters…or because someone’s
eclipse made unrelated whitespace changes…
cheers,
Leo
[1] http://yarchive.net/comp/linux/git_merges_from_upstream.html
https://lkml.org/lkml/2008/5/21/351
http://lwn.net/Articles/328438/
…etc…
