Branches and workflows

[Arne Babenhauserheide]

František Kučera <konference at frantovo.cz> writes:

> Dne 18. 11. 19 v 22:24 Arne Babenhauserheide napsal(a):
>> One of the most accessed articles on my website is the hg branching
>> strategy: https://www.draketo.de/branching-strategy
>> >> 3 simple rules:
>> >> (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).

> Thanks for a great article. I have very similar workflow with only
> difference – the names of the default and stable branches. With semantic
> versioning I derive the tags and branch names from the semantic
> versions. So e.g. the version 1.2.3 is in Hg tagged as v1.2.3 and
> development of 1.2.* versions (patches) happen in the v_1.2 Hg branch.
> Minor versions like 1.* are developed in the v_1 branch. Then we can
> have two (or more) parallel development streams – while 1.* versions
> (not only hotfixes, but also new features) are developed in the v_1
> branch, the next big release is being prepared in v_2 branch. The v_1.2
> branch is forked from the v_1 branch and v1.2.0 tag (not automatically –
> only when we know that we are going to release v1.2.1 hotfix). Changes
> are merged up through the branches – e.g. v_1.2 → v_1 → v_2.
>
> It might look too bureaucratic, but usually the number of branches is
> the same as with default/stable workflow – the branches have just
> different names reflecting the semantic versioning and it is IMHO more
> flexible and more explicit (everyone know, to which version the commit
> will go – just from the branch name).
>
> What do you think about this workflow?

It sounds slightly more complicated than just stable and default, but
the only real disadvantage I can see is that you have to decide when you
branch how the next release will be called.

And that there’s often the need for continued development in multiple
versions is a sad reality.

Are you always merging all changes up to v_2?

If you want to adapt the graphics in my article to visualize your
workflow, feel free to take them. They are created from a ditaa-source:
https://www.draketo.de/files/2012-09-03-Mo-hg-branching-diagrams_13.org

> My latest experience if from a project with 3-5 developers, 3 years and
> few customers (no customer branches, but different upgrade schedules)
> and I think that this workflow worked well.

Thank you for sharing your experience!

Best wishes,
Arne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1076 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20191121/7059ef2f/attachment.asc>