On 19/08/08 at 21:20 +0200, Thijs Kinkhorst wrote: > > 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 is the current stable major release > > number, and Y is the current minor release number for a stable > > upload, or one higher than that for a testing upload. Z is a > > counter starting at 1. 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, while a security NMU to Lenny > > would get version 1.5-3+deb41u1. This is the case even when it > > is already known that the next release will be a new major > > version ; for instance, Lenny will be released as Debian 5.0. > > I am not very happy with this paragraph. The proposed scheme is in my opinion > hard to read, and it gets especially confusing when 40 means 4.1 and 41 means > 5.0. > > We already have a scheme in the security team that prevents this numbering > confusion, and that is to use release codenames. It makes it clear at a > glance whether a package is intended for stable or testing, and the codenames > do not change. > > The current convention is to add +etch1 or +lenny1 respectively. This scheme > works well. It would fail when we have a release name starting with "a", but > that situation doesn't exist and can be easily prevented. The scheme was > recently changed to cope better with binNMU's, and I'm not sure what the > benefit would be to change it yet again within a few months. The problems we > have, like today with postfix, are when maintainers use the old scheme which > is indeed suboptimal. > > I'm unclear on the reasons of changing the current system. It works, so why > change it? I prefer to codify existing practice than the other way around in > this case. Let's try to converge on this discussion. What's the problem with the current scheme of using etch1, lenny1, etc? Look at the following (hypothetical) timeline: * User uses sarge, and installs package P version 1-1sarge1. * User upgrades to etch. In etch, there's P version 1-1etch1, that fixes the same security problem as P 1-1sarge1. since 1-1sarge1 > 1-1etch1, user keeps 1-1sarge1. No big deal. * Sarge reaches end of support. * Another security issue is discovered in P. P version 1-1etch2 is uploaded. Since 1-1sarge1 > 1-1etch2, user still doesn't upgrade, and stays affected by the security issue. A similar problem exists with NMUs. Conclusion: we need a way to version stable/testing uploads that avoids this. The proposed solution was to use +debXYuZ, with XY being the major/minor release number (4.0 for etch, 5.0 for lenny, etc). But there's a problem when the new release number is not yet known (is lenny+1 going to be 5.1 or 6.0?). In the proposed solution, the conservative choice was used: use the smaller release number higher than the current stable release number (ie 4.1 for lenny). That's obviously confusing. 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? -- | Lucas Nussbaum | lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature