Request for comments about using named branches to track releases

[Mario Castelán Castro]

On 25/08/17 02:54, Arne Babenhauserheide wrote:
> 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.
There is no strict need, as this is for a small and currently private
project, but yes, I would like to avoid having seemingly “stable”
version numbers in-between actual releases.

> 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

This model looks good to me. It is *roughly* the model that most people
follows, but “rougly” is too vague. Of course, undocumented software is
incomplete software and the same goes for VCS workflows! I appreciate
that you took the work to publish a clear documentation for a VCS and
release workflow.

-----
Thanks for your reply.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://www.mercurial-scm.org/pipermail/mercurial/attachments/20170826/62c750e1/attachment.sig>