Re: [PATCH] Specify policy for use of revision IDs in version numbers

[Osamu Aoki <osamu@debian.org>]

Hi,

On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote:
> Ben Hutchings <ben@decadent.org.uk> writes:
> 
> > +	  <p>
> > +	    The upstream version number must not include a non-linear
> > +	    revision ID or hash, since it cannot help in ordering
> > +	    versions and it tends to result in very long version
> > +	    numbers and filenames.  This information may be recorded
> > +	    in the changelog instead.
> > +	  </p>

It is a bit detailed and lacks limitation for length but I think it is a
good start.

The above goes to as 3.2.2 as I understand.  We already have "3.2.1
Version numbers based on dates" and fits nicely into the context.

Let's add this.

> I don't think it's Policy's place to tell people that they can't use
> hashes because they *might* result in long version numbers.  They usually
> don't.

This is another topic.  I do not think everyone agreed yet to a
particular set of numbers.  The more I looked into this issue, I think
followings are the possible numbers:

 * package file name for normal uploads: 90 characters (must)
   - rationale: UCS-2 requirement etc.
   - current longest is 76 chars.
   - this number is ready for policy.

 * package name length <=40 (must:   99.8% qualifies)
 * package name length <=30 (should: 98.3% qualifies)
   - aptitude field length default

normal version length withour special extension such as +nmu? +b? ...
should be:

 * version length <=30 (must:   99.9% qualifies)
                  <=20 (must:   99.0% qualifies) possible alternative.
 * version length <=15 (should: 95.3% qualifies)
   - aptitude field length default can be 15 as BTS #624542 for 80 char/line
   - 10 is too short since only 83.8% qualifies.

I understand some may feel general recommendation to be in "Developer's
reference" in general as:

5.11.2. NMUs and debian/changelog
 http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-changelog
 This only talk about NMU versioning.

6.3. Best practices for debian/changelog
 http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog
 
These are a bit more guidance than limiting version number for what we
can use.

> If we have a version number length restriction, or an overall filename
> length restriction, we should just say that, and point out that using
> hashes may make it hard to meet the restriction.

If we do this, we also need to move 3.2.1 to developers-reference.

Osamu