Request for comments about using named branches to track releases

[Nicolas Pinault]

Hi,

On my side, the "version" file is not in the repository.
Each developer manages its own file with the numbering scheme he likes.
The PC on which public versions are created also uses its own file and 
uses official numbering scheme.

Nicolas

Le 25/08/2017 à 04:37, Mario Castelán Castro a écrit :
> 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.
>
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial


-- 
*Nicolas PINAULT
R&D electronics engineer
*** nicolas at aaton.com <mailto:nicolas at aaton.com>

*AATON-Digital*
38000 Grenoble - France
Tel +33 4 7642 9550

http://www.aaton.com
http://www.transvideo.eu
French Technologies for Film and Digital Cinematography

Follow us on Twitter
@Aaton_Digital
@Transvideo_HD

Like us on Facebook
https://www.facebook.com/AatonDigital

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial/attachments/20170828/4bd6af24/attachment.html>