Request for comments about using named branches to track releases

Mario Castelán Castro marioxcc.MT at yandex.com
Sun Aug 27 01:28:05 UTC 2017


On 25/08/17 01:27, Steve - Gadget Barnes wrote:
> 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.

Yes, I know that many projects do it that way. That is why I mentioned
explicitly that I want to avoid this. With projects that are easy to
build, one can release the tarball with exactly the files that appear in
the release changeset, verbatim. However, if the release tarball depends
on information generated from the .hg directory, then the released
tarball will not be identical to the corresponding changeset.

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

No, I mentioned it in my first message.

> 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/).

I see. This is a good suggestion to give meaningful names to branches
and I will take it into account, but it is unrelated to my original query.

> You are also missing the semantic versioning concepts of alpha, beta & 
> release candidates

You seem to be confused here. Semantic Versioning (at least 2.0.0) does
not specify any semantics for pre-releases. Hypothetical versions with
“-rc”, “-alpha” and “-beta” are mentioned in the Semantic Conversioning
documentation only as examples.

> 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.

“Continuous integration” does not appeal to me at all. Having a central
server running 24/7 to run tests looks to me like spoon-feeding of
irresponsible programmers. In my view, it is the comiter's obligation to
check that his changesets pass all tests, and to introduce any new test
necessary, before pushing. The “integration server” is just a waste of
time and CO2 emissions if everybody does what is supposed to do.

-----
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://lists.mercurial-scm.org/pipermail/mercurial/attachments/20170826/f3ad5fb6/attachment.asc>


More information about the Mercurial mailing list