Branches and workflows

[František Kučera]

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?

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.

Franta