Request for comments about using named branches to track releases

[Arne Babenhauserheide]

Hello,

Mario Castelán Castro <marioxcc.MT at yandex.com> writes:

> Suppose I want to have at least 2 named branches in a repository, one
> “stable” and the other “development” so that *all* development happens
> in “development” (or any branch but “stable”). The only changesets in
> “stable” will be merges from “development” or changes affecting only the
> literal version string and tagging.
…
> Now the questions are: When should the version number be changed? What
> value should the version string have on the “development branch”?
> Exactly what changesets will be on “stable”?
>
> Option 1: The development branch always has a special value
…
> Option 2: The development branch always has a value like “1.2.8-dev”
…
> Option 3: Like option 2, but branches are interleaved and there are no
> spurious merges.
…
> Option 4: Like option 3, except that the first commit that makes the
> release is a merge which  previous tag commit as the first parent, and

> I request comments addressing reasons to choose one option instead of
> another. Suggestions for alternatives to options not listed here are
> welcome. Also please let me know if there is a well established
> convention in the Mercurial community.

The model which works well for me is to change the version in the source
code in the default branch, then merge to stable (with the commit
message giving a one-line description of the changes in the new
release), then tag and sign on stable and merge back to default.

This ensures that the description of the tagged merge commit is
well-formed and stable only contains release-merges, tagging and
signing.

Do you need to give changed version numbers during development? If yes,
I would use option 2, since this will always make it clear what release
development is based on.  I’d adjust the version just after the merge
from stable to default. Then there will never be a *-dev version on
stable.

I use the standard "default" branch as development branch and named
branches on top of it.

I described that workflow in http://www.draketo.de/branching-strategy

    (1) you do all the work on default - except for hotfixes.
    
    (2) on stable you only do hotfixes, merges for release and tagging
        for release. Only maintainers touch stable.
    
    (3) you can use arbitrary feature-branches, as long as you don’t
        call them default or stable. They always start at default (since
        you do all the work on default).
    
Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial/attachments/20170825/980f969c/attachment.sig>