On Thu, 22 Jan 2004 10:36:34 -0500, Lamar Owen wrote: > But if you do not bump the release number, you get into a situation of WHICH > version of the release is really the release. In a bugzilla ticket, the most recent package update comment from the packager contains the name and a link to the most recent package revision which will be reviewed. In an approval, the reviewed and approved package is specified with a clearsigned MD5 fingerprint. There are no ambiguities. It's mandatory that a package update request starts with a release number which is high enough. But changes applied to the package during the review phase need not increase the release number. However, most packages do increase the release number with every package revision. So, this whole discussion is wasted time [until we have different requirements due to an automated build system or package submission process]. > But having two packages with identical E:V-R but different contents is > terrible, even if it is within the QA queue. Even more terrible is the difference between theory and practice. I've reviewed and approved a high number of packages at fedora.us, and it is a pain to request another package update just because with his latest package modification, the packager forgot to increase the release number once more or didn't add a changelog entry for trivial fixes. Requesting a new package just for an increased release number would be one of the things that make us few QA people look like we're the pedantic bad guys who turn package submission and approval into an overly tiresome process. If an updated package builds and works as expected and has a release number which is high enough for it to not cause any conflicts when published, I don't care whether each package update increased the release number. It has happened before, it will happen again, please make the packager's job easier. Encourage packager to increase the release number strictly, but don't make it mandatory until there is a specific requirement for it to be mandatory. --
