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. Thijs
Attachment:
pgp9K_MfneIb2.pgp
Description: PGP signature