[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP1: Non Maintainer Uploads (final call for review)

On Friday 22 August 2008 15:49, Lucas Nussbaum wrote:
> Conclusion: we need a way to version stable/testing uploads that avoids
> this.

While I'm not convinced that it's a pressing issue that needs resolving, if 
people badly want it I'll use the new system.

> I think that instead, we should use this "conservative choice" until the
> real release number is known, and then switch to the announced release
> number. If the release team changes its mind, well, we have a problem.
> But that's probably something we can deal with.
> As a consequence, I propose the following wording for the paragraph of
> developers-reference about that:
>    If you upload a package to testing or stable, you sometimes need
>    to "fork" the version number tree. This is the case for security
>    uploads, for example. For this, a version of the form +debXYuZ
>    should be used, where X and Y are the major and minor release
>    numbers, and Z is a counter starting at 1. When the release
>    number is not yet known (often the case for testing, at the
>    beginning of release cycles), the lower release number higher
>    than the last stable release number must be used. For example,
>    while Etch (Debian 4.0) is stable, a security NMU to stable for
>    a package at version 1.5-3 would have version 1.5-3+deb40u1,
>    whereas a security NMU to Lenny would get version 1.5-3+deb50u1.
>    After the release of Lenny, security uploads to the testing
>    distribution will be versioned +deb51uZ, until it is known
>    whether that release will be Debian 5.1 or Debian 6.0 (if that
>    becomes the case, uploads will be versioned as +deb60uZ.
> Would that work for everybody?

I'm not sure why we can't just agree to set the release number of n+1 before n 
is released? That would make the proposal significantly less complex.


Attachment: pgpBVEYMfhuOm.pgp
Description: PGP signature

Reply to: