Re: Version numbering for security uploads of native packages
Russ Allbery dijo [Wed, Mar 19, 2008 at 12:05:53PM -0700]:
> >> Yes, sorry. I forgot that those exist as well. :-)
>
> > Why are we bothering to make something up if everyone is using etch<nr>
> > etc?
>
> 1.0-1sarge1 >> 1.0-1etch1. We don't have this problem currently because
> 1.0-1etch1 << 1.0-1lenny1, but we will again at some point in the future,
> and it would be nice to resolve it once and for all. Using something
> based on the Debian release version has the advantage that the version
> always increases from release to release. The code names bounce all over
> the place in version sorting space.
Umh... With release cycles close to 18 months, this would mean tha,
being I a bad and lazy maintainer, I didn't touch my native package
for over three years. Say, version 1.0 was released with Sarge, in
2005. At some point in 2006, a serious flaw is addressed via a NMU, so
it sits at 1.0+sarge1. I still cannot be bothered to take a look at
the damn package. Time passes. In March 2008 it (again) shows it needs
to be taken care of, and you kindly prepare a new NMU, properly
labeling it 1.0+etch1.
It gets rejected, as it is a lower version.
I have not touched the package for three years at last. Tell me, don't
you think this should trigger some QA alarms? At very least, I'd agree
with you uploading 1.~1+etch1. That way, when I'm finally done with my
Precious 1.1 release, I can still properly upload it without any fuzz.
Greetings,
--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Reply to: