Hi,
On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote:
> Ben Hutchings <b...@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
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501003325.ga3...@debian.org
