Re: limits for package name and version (MBF alert: ... .deb filenames)

[Jakub Wilk <jwilk@debian.org>]

* Ben Hutchings <ben@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