Re: Question: next, master and pu branches

Alexander Litvinov [off-list ref] writes:

Can somebody explain the meaning of next and pu branches and
some documenation about using topic branches.

My development model use two branches now: stable release and develment 
branch. All changes in the stable release branch are bug-fix only changes. 
All (or most) of them must go to development release. Now I do this using 
cherry-pick but it is not easy to track what was merged especialy when merge 
pruduce confic resloved by hands. Stable branch live long life, much more 
than 100 commits. 

I think what you are looking for is how my 'maint' and 'master'
branches are maintained; 'maint' corresponds to your "stable
release" while 'master' corresponds to your "develment branch".

When a stable release is cut, 'maint' is forked from there.

Truly obvious corrections will be applied on top of the tip of
'maint' directly, while if there are any doubt about a proposed
change I might fork a topic off of the tip of 'maint' and cook
the fix for a while until I finally merge it to 'maint'.  This
way, 'maint' will be "bugfix only since the last release".

The tip of 'maint' will be merged into 'master', from time to
time, to make sure that all fixes will be in 'master'.

When it is time for a new release to be cut, I'd make sure that
the tip of 'maint' is merged into 'master' (it usually is) and
then the tip of the 'master' is tagged to be released.  After a
release is made, I could have two maintenance branches (one that
continues on top of the old codebase, another that fixes the new
release).  A fix that can apply to both codebases will be
applied to the maintenance branch for the old release and then
its tip can be pulled into the maintenance branch for the new
release and then its tip can further be merged into the
development branch.

At some point, the codebases for the older release and the
current release become diverged enough that merging could become
inpractical (the same bug may need different fix if the
infrastracture has become different); you would need to bite the
bullet and fix it twice (i.e. differently).

I think what you are looking for is how my 'maint' and 'master'
branches are maintained; 'maint' corresponds to your "stable
release" while 'master' corresponds to your "develment branch".

When a stable release is cut, 'maint' is forked from there.

Truly obvious corrections will be applied on top of the tip of
'maint' directly, while if there are any doubt about a proposed
change I might fork a topic off of the tip of 'maint' and cook
the fix for a while until I finally merge it to 'maint'.  This
way, 'maint' will be "bugfix only since the last release".

The tip of 'maint' will be merged into 'master', from time to
time, to make sure that all fixes will be in 'master'.

When it is time for a new release to be cut, I'd make sure that
the tip of 'maint' is merged into 'master' (it usually is) and
then the tip of the 'master' is tagged to be released.  After a
release is made, I could have two maintenance branches (one that
continues on top of the old codebase, another that fixes the new
release).  A fix that can apply to both codebases will be
applied to the maintenance branch for the old release and then
its tip can be pulled into the maintenance branch for the new
release and then its tip can further be merged into the
development branch.

At some point, the codebases for the older release and the
current release become diverged enough that merging could become
inpractical (the same bug may need different fix if the
infrastracture has become different); you would need to bite the
bullet and fix it twice (i.e. differently).

Thanks for detailed description. As a cunclusion I would like to say: all bug 
fixes are made in the stable branch and then stable branch will be merged to 
development branch. That is easy !