Request for comments about using named branches to track releases

[Mario Castelán Castro]

Hello.

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.

The program must print its own version when requested. The version must
be present somewhere in the source; it can not be generated at
compile-time by calling Mercurial. Obviously each release will have a
unique version. 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 outside the
normal versioning scheme like “dev”. When a release is made, exactly 2
commits are made in the “stable” branch: (1) Merge “development” and in
the *same* changeset, set version to a normal value like “1.2.9”. (2)
Add a commit with “hg tag” to tag the new release.

Option 2: The development branch always has a value like “1.2.8-dev”
where “1.2.8” is the latest release already made (The changesets before
before the first release must obviously use a different scheme). When a
release is made, 3 commits are made: (1) Change version to a normal
version number like “1.2.9”. (2) Add a tag for the previous changeset,
which marks the release. (3) Create a merge from the changeset of (2) to
“stable”. Note that then the “stable” branch is only merges, except
possibly for the first changeset. Any further commit before the next
release *must* add the “-dev” part to the version string.

Option 3: Like option 2, but branches are interleaved and there are no
spurious merges. The same convention for the version string and release
changesets are followed as in (2), except that *only* those 2 changesets
pertain to “stable” and there is no merge. The first commit that makes
the release is made *on top* of the latest development commit.

Option 4: Like option 3, except that the first commit that makes the
release is a marge 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.

Thanks.

-- 
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/20170824/8d9a440f/attachment.sig>