Inconsistencies in package versions for stable releases

[Simon Quigley]

Hello,

This email is following several discussions I have had over the past few
weeks on how the versioning scheme of packages work with respect to
stable releases.

It seems there is some inconsistencies with SRU team members accepting
different-versioned packages due to somewhat varied standards. Some
people say that the Security Team document on versions[1] is the
(lowercase c) canonical document on how things should be versioned,
while others just say "as long as the version isn't a problem."

As someone who has had their packages rejected before because the
version did not match the former of the two preferences, I think it is
worth having a discussion on how we should do version numbers in a
uniform and agreed-on way.

Here are some uploads that I would have probably seen rejected depending
on the SRU team member because of the version:
https://launchpad.net/ubuntu/+source/snapd/2.33.1+18.04ubuntu2
https://launchpad.net/ubuntu/+source/ubuntu-report/1.2.0~bionic
https://launchpad.net/ubuntu/+source/shim/13-0ubuntu2

With snapd, it seems to be somewhat inverted from the typical case,
where Xenial gets the native package upload with no additions, Xenial+
gets +XX.YY, and Trusty- gets ~XX.YY.

With ubuntu-report, I have always been discouraged from using codenames
in the version number, because if, for some reason, we needed this in
Xenial, being consistent with the naming scheme wouldn't work:

$ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~xenial"; echo $?
1
$ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~16.04.1"; echo $?
0

This means we would have to be inconsistent across releases.

With shim, I have also been discouraged from doing ubuntuX, as opposed
to ubuntuX.Y. In this case, I would have gone with 13-0ubuntu0.2.

My objective in pointing these out is not that these versioning schemes
do not work, or to pick on any one package or person. My point is, they
lack consistency with the rest of the archive, and some of these do not
work in other cases where a variable has changed. Most importantly
though, I have observed varied tolerance among the SRU team for these
version numbers.

Is the existing document by the Security Team[1] lacking any important
considerations? Can we adopt it as the uniform standard for updates in a
stable release, or is there a good reason to continue with inconsistency
here?

Thanks.

[1]
https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging

-- 
Simon Quigley
tsimonq2 at ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20180705/ab06ee31/attachment.sig>