Anthony Towns <aj@azure.humbug.org.au> writes: > Goswin von Brederlow wrote: >> 1.rc << 1.rc2 << 1.rc+b1 >> 1.2-1~beta << 1.2-1~beta2 << 1.2-1~beta+b1 > > 1.2~beta-1 << 1.2~beta-1+b1 << 1.2~beta2-1 > > Keeping the Debian revision simple is a Good Thing. > >> Adding the implicit '0' that dpkg assumes on versions ending in alpha >> chars would solve both cases: > > That'd mean REJECTing uploads whose versions match > "[^0-9]+[a-z][0-9]+$" presumably.
No, why? A version matching "[a-z]$" has an implicit trailing 0 in dpkg version terms. When adding a + that implicit 0 must be added explicitly to preserve the ordering. With that rule there is no reason to rstrict the version to exclude "[a-z]$". >> Another case that should be considered is the existing use of + for >> revisions of a cvs snapshot (e.g. mutt uses a + but always does so): >> 1.2-20041208 "<<" 1.2-20041208+2 "<<" 1.2-20041208+b1 > > Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the > upstream version? Or "1.2-20041208-1", or "1.2+cvs20041208-1" or > whatever. > > -rw-rw-r-- 16 katie debadmin 2908273 May 2 2004 > pool/main/m/mutt/mutt_1.5.6.orig.tar.gz > -rw-rw-r-- 16 katie debadmin 412082 Nov 17 10:17 > pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz > > It seems to result in rather large diffs, and I can't really see the > benefit? > >> There are 3 simple solutions to this: >> 1. forbid + in debian versions and think of another character instead >> doing the same (must be < '.') > > Actually, that doesn't work either -- otherwise a new maintainer > version (x-y#1) compares less than an old NMU (x-y.1). For the same > reason "= ." doesn't work. Right, so a debian version may only be extended by characters that compare > '.'. That should be noted somewhere. > Cheers, > aj MfG Goswin