Hi,
On Wed, Apr 27, 2011 at 03:11:14PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 26 Apr 2011, Uoti Urpala wrote:
...
> It is still not a good reason to waste part of a draconian 30 chars of space
> with hash information.
I agree.
Anyway, I think 30 should be the absolute upper limit for policy. This
should not be used casually as the length for most softwares. aptitude
only displays 10 characters. Debian revision part (-1) uses 2. So if we
want to offer best user experience, 8 should be the top value for most
programs if this is possible.
(Quite frankly, aptitude default of 10 may be too short.)
For me even bzr/git/hg/... seems useless information as a part of
version. My idea for nicer versioning schemes are the following.
0~YYMMDD for any package checked out from VCS on the day
or for renaming package with brain dead version string
0~YYMMDD.1 if you need to make second version after your mistake :-)
0.YYMMDD for any package checked out from VCS on the day and you
know upstream will be releasing 1.x soon.
1.2.10~YYMMDD for prerelease of version 1.2.10
1.2.10~rcYMMDD for prerelease of version 1.2.10 (alternative format)
this last 2 are mostly used in unstable/testing only. So length is
less of problem.
+b is nice but +nmu seems redundantly long. I wish things are simpler
like:
1.2.10+b1 for binNMU
1.2.10+n1 for nmu to unstable
1.2.10+r1 for stable update
1.2.10+r2 for stable update if r1 existed.
1.2.10+u1 for derivatives like Ubuntu repackage?
1.2.10+x1 for derivatives repackage
I also wish NMU versioning for Debian revision become in line with the
above practice. So suffix rules are the same for native and non-native
packages.
For now, I updated maint-guide just based on facts only with milder
wordings without above idea as:
http://www.debian.org/doc/manuals/maint-guide/first.en.html#namever
http://www.debian.org/doc/manuals/maint-guide/first.en.html#ftn.id380278
http://www.debian.org/doc/manuals/maint-guide/first.en.html#ftn.id380318
(For now, I am keeping old YYYYMMDD style.)
Osamu
--
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/20110428145548.gb20...@debian.org
