Just a few cents from me as an SRU member. There is no 'inconsistencies' among the SRU team regarding versioning as there is no 'standard' way of versioning packages. Rejection of a package because of the versioning scheme, to me, is only a case of preference and can vary between SRU members. There is no standard that we're trying to force, and no SRU member should enforce that. We *recommend* the security team's versioning scheme as it's the most logical, but some of us also generally aim for consistency. So if a package already used a different scheme for the selected series or others, this is the way to go. Sometimes we accept a differently versioned package as a 'one-time-off' (e.g. ubuntu-report), or sometimes a package follows it's own, rather complicated, different release model (e.g. snapd).
In my view the ubuntu-report scheme is the most invalid, but it has been accepted conditionally as the package was not targeted for backporting to anywhere else than bionic. I should have probably rejected it and re-uploaded with a more fitting versioning applied, as I did for a few others like this. But as I said, there generally is no standard we *need* to enforce, so as long as the version works - there's no requirement for rejection. We should keep advertising the security team's versioning as the best way to go, but right now - for what I can tell - there are no rules for that. Cheers, On 6 July 2018 at 06:15, Simon Quigley <[email protected]> wrote: > 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 > [email protected] > tsimonq2 on freenode and OFTC > 5C7A BEA2 0F86 3045 9CC8 > C8B5 E27F 2CF8 458C 2FA4 > > > -- > ubuntu-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Łukasz 'sil2100' Zemczak Foundations Team [email protected] www.canonical.com -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
