Request for comments about using named branches to track releases

[Steve - Gadget Barnes]

On 25/08/2017 03:37, Mario Castelán Castro wrote:
>   it can not be generated at
> compile-time by calling Mercurial.

Why not? It is reasonably usual in many VCSs and Development Work Cycles 
to do exactly that for compiled languages and for interpreted languages 
such as python to have a "Publish" or "Release" step that uses the VCS 
to update/create a version information file of some form that provides 
the information.  I have been doing exactly this for years in svn, git & 
hg.

You also neglected mentioning the hg tag option which is often used to 
mark releases of the trunk.

Some of the places that I have worked have used a branch & version 
naming scheme that followed the convention of:

Bug Fix branches were given a name (and generated version number) of 
version.to.be.fixed+fix_id while new features were 
next.version.number-feature_id which is generally in line with semantic 
versioning, (http://semver.org/).

Another "trick" that I have used a lot is to have a reserved couple of 
version numbers that are used whenever there is uncommitted code present 
or mixed versions of committed files, again generated at build/publish, 
that alert everybody on the team that they are looking at a bad build.

You are also missing the semantic versioning concepts of alpha, beta & 
release candidates, where you would have develop on dev branches, early 
attempts at the next version would be next.version-alphaN (team internal 
testing only) and next.version-betaN (wider testing) where N is 
sequential followed by next.version-rcN (release candidates for most 
extensive or public testing). Obviously these would be on a next.version 
branch but would normally be distinguished by tags.

The other thing that I think is missing from your list of options is the 
possibility of involving a Continuous Integration tools such as Jenkins, 
Hudson, etc. - in this context pushes to the main trunk are never done 
manually - instead a candidate is marked manually as such, detected by 
the CI tool, checked out and appropriate version information added, 
tested and if all the tests are successful the new version on the trunk 
is created by the CI tool.

-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com