Hi, Sorry for breaking the thread and chiming in late, I was until recently not aware of this thread and not subscribed to debian-project. I hope my comments can still be considered.
> The version must be the version of the last upload, plus +nmuX, > This special versioning is needed to avoid stealing one of the > package maintainer's version numbers, which might disrupt their > work. The past weeks I had several encounters with the situation that a maintainer completely overlooked and NMU and uploaded a newer version without acknowledging the previous NMU, thereby reintroducing the problem the NMU addressed. This happened to active maintainers. I was wondering why we version NMU's differently from MU's. If they used the same scheme, in these cases the subsequent upload from the MU would have been rejected. That would have flagged a problem for them and they had discovered the NMU they forgot to integrate. Of course it wouldn't help in any situation but it would have helped these. I do not really buy the "stealing" argument since maintainers do not "own" version numbers. It indeed interferes with their work but it *needs* to. A completely ignored NMU has been rendered ineffective. > 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. cheers, Thijs
pgpybwIX3a6FK.pgp
Description: PGP signature
