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 <tsimonq2@ubuntu.com> 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
> tsimonq2@ubuntu.com
> tsimonq2 on freenode and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
--
Łukasz 'sil2100' Zemczak
Foundations Team
lukasz.zemczak@canonical.com
www.canonical.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
