* Ben Hutchings <b...@decadent.org.uk>, 2011-04-23, 15:06:
[...]
=== version, strings longer than 30 (unique ones) ===
0.9.15+post20100705+gitb3aa806-2
0.0.0+git20091215.9ec1da8a-2+b2
1.0.0~alpha3~git20090817.r1.349dba6-2
1:2.5.0~alpha4+svn20091009-1+b2
2.1.14+2.6.32.13-201005151340-1
1:2.2cvs20100105-true-dfsg-5+b1
0.9.8+hg20101101.b35a000870cc-1
0.5.10~alpha0+git201005030944-2
1.1.1+ooo-build3.0.0.9+r14588-9
1.2.0~pre3+snap20071004+dfsg-3+b1
3.0~a2+hg1075.9a478044c65c~dfsg1-1
Clearly, all of these are able to wrap name within 30 chars.
[...]
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered, and the information about exactly which commit the
snapshot was can be included in the changelog.
Seconded.
Mercurial revision numbers should not be used either as they are not
consistent between repositories
But they are stable within a single repository (as long as you don't
perform lossless operations). And usually there is exactly one
well-defined upstream repository, so if you know what you are doing
(i.e., use their numbering), revision number can be good enough.
(they really were a stupid idea in a distributed VCS).
Local changeset identifiers are convenient; it's faster to type a few
digits than to copy&paste a hash.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110429233251.ga8...@jwilk.net
