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
> > 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.

Re: Version numbering for security uploads of native packages

Gunnar Wolf writes:
> Russ Allbery dijo [Wed, Mar 19, 2008 at 12:05:53PM -0700]:
>> 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.

Sure, and this is why we haven't seen much problem with this. I think I
remember only seeing one of these between sarge and etch. But there was
one, and since it's a simple problem to solve by picking a somewhat more
predictable versioning scheme, it seems worth the minor effort.

There are packages where the only updates between two releases are for
minor things like standards-version or Vcs and Homepage headers that
aren't horribly vital. They're rare, but they do exist. I've not
uploaded a new version of sident since the etch release, for example, and
while I plan to do so when I have time to clean up some minor stuff,
nothing would be fundamentally broken about it if I didn't. It's less
likely that this would happen in combination with non-maintainer or
non-unstable updates that would provoke this versioning, but I can see it
happening.

Re: Version numbering for security uploads of native packages

Gunnar Wolf writes:
> 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.

how about having it uploaded as 1.0+sarge1+etch1. looks funny, but
actually follows the policy that says to 'append' +etch1 to such uploads.

Re: Version numbering for security uploads of native packages

On 2008-03-16, Adam D. Barratt wrote:
> On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote:
>> The current binNMU numbering scheme was selected explicitly to allow
>> security uploads to sort later by numbering as
>> +; e.g., 1.2-5.1+etch1.
>
> That makes sense, although doesn't seem to match current practice. Was
> any consideration given as to where NMUs of native packages should sort?
> (I realise that they're the only case that doesn't automagically dtrt
> with respect to the numbering scheme).