Comment 2 for bug 1779859

Revision history for this message
Daniel Manrique (roadmr) wrote :

Debian ordering can be implemented with apt_pkg (modulo horrid python with outdated cmp usage):

import apt_pkg # this required python-apt deb package, we'd need to add as a store dep
apt_pkg.init_system()
sversions= sorted(versions, cmp=lambda x, y: apt_pkg.version_compare(x, y))

Given this list of versions (I randomized it but the patterns mostly match real track names, save for 1.11~ubuntu1 and 2.0+gitdeadbeef which I threw in just to showcase possible debian ordering particularities):

['1.8',
 'ocata',
 '1.12',
 '1.11~ubuntu1',
 '1.10',
 'lts',
 '1,1',
 '2017.10',
 'latest',
 '1.11',
 '2017.1',
 '2017.2',
 '1.9',
 '2.0+gitdeadbeef']

it orders them like so:

['1,1',
 '1.8',
 '1.9',
 '1.10',
 '1.11~ubuntu1',
 '1.11',
 '1.12',
 '2.0+gitdeadbeef',
 '2017.1',
 '2017.2',
 '2017.10',
 'latest',
 'lts',
 'ocata']

which looks acceptable particularly regarding ordering of numeric versions (i.e. 1.9 comes before 1.10 and 1.11), save for one thing: "latest" is the default track but it goes just somewhere in the list. A suggestion was to always put "latest" at the top and let the rest of the list follow the desired ordering, like:

[
 'latest',
 '1,1',
 '1.8',
 '1.9',
 '1.10',
 '1.11~ubuntu1',
 '1.11',
 '1.12',
 '2.0+gitdeadbeef',
 '2017.1',
 '2017.2',
 '2017.10',
 'lts',
 'ocata']

For a realer example of a snap with lots of tracks, GO has 1.x tracks and latest:

curl -H "Snap-Device-Series: 16" https://api.snapcraft.io/v2/snaps/info/go?fields=name,snap-id | jq '."channel-map"[].channel.track' | uniq
"latest"
"1.10"
"1.11"
"1.6"
"1.7"
"1.8"
"1.9"

with the debian ordering and suggested promotion of latest this becomes:

"latest"
"1.6"
"1.7"
"1.8"
"1.9"
"1.10"
"1.11"