tracks should be ordered

I think Debian version ordering makes sense, and I would prefer not to implement an "ordering" field because it makes track management more unwieldy, also remembering that track creation is not yet handled directly by developers but by request on the forum.

If other teams/clients reorder tracks at their leisure it will make the store ordering somewhat irrelevant, so I think we should coordinate with other clients/teams using this (as you mention, there's at least snapcraft.io and snapd to consider, and we also need to look at gnome-software perhaps, they may rely on what snapd gives but maybe not... you get the point).

Given that there are a number of teams or stakeholders which might be interested/involved, does a forum conversation sound like a good place to discuss this? (maybe there is one and I missed it). Store-side we can implement ordering but would be good to have consensus on what makes sense, and I get the feeling the bug report is not a great place to have that cross-team conversation.

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"

An interesting case is:

curl -H "Snap-Device-Series: 16" https://api.snapcraft.io/v2/snaps/info/etcd?fields=channel-maps-list,name,snap-id | jq '."channel-map"[].channel.track' | uniq

"latest"
"2.3"
"3.0"
"3.1"
"3.2"
"ingest"

The original request in this bug is "There should be a well-defined order for tracks.".

They are ordered alphabetically save for "latest" which always appears first. Alphabetical ordering may not make the most sense for numeric track names, but it *is* a well-defined order. That said, if something that handles numeric names more nicely (as we've seen Debian ordering does) is preferred, we can look into it.

The current ordering seems to be (but is not documented to be, afaik) alphabetical, except that latest comes first. This obviously breaks down for projects that want to use version numbers for tracks, such as go, or even etcd itself as soon as it reaches two-digit version numbers.

Version sort would cover those, but not cover projects that want to use some other descriptor (for example, chrome might use stable/beta/dev/canary).

We could look at everything that has tracks today and see how they want them sorted, and use those numbers to inform the decision. I'm not sure that's wise at we're not yet where we want to be in terms of adoption, though.

In any case it's a sufficiently broadly-impacting issue and feature that I think it needs wider (and higher) commentary.

This sounds like a simple enough issue that we could just move forward with an preliminary agreement. How about this:

- Latest comes first followed up by everything else, version-comparison-ordered, reversed

?

We can change the store first so it returns this, then see it in practice, and once that's in place communicate with all client stakeholders to not sort locally so we have a consistent listing.

Here is the deb algorithm in pure Python and in a single file, if that's useful:

https://github.com/smartpm/smart/blob/master/smart/backends/deb/debver.py

To be clear, we'd see something like this in practice

- latest
- 3.2
- 3.1
- 2.3

The "Latest comes first followed up by everything else, version-comparison-ordered, reversed" makes total sense when having 'latest' and all revision numbers, but we have more complex scenarios.

I'm working in adding "the default track first" to the ordering, and found that current behaviour is not what I'd expect when talking about non-version strings.

So, excluding default track (always first, when exists) and 'latest' (always first, except when a DT exists, in that case it goes second), we all agree in the following orderings:

- 3.11
- 3.10
- 3.9

or

- foo
- 3.11
- 3.5

... but what about having several normal ("non version") strings? why it should be reversed?

Example, having foo, bar and baz tracks, shouldn't those "normal strings" be *forward* ordered between them?

- bar
- baz
- foo

In a more comprehensive example:

- 3.12 # current developer-specified default track!
- latest
- bar
- baz
- foo
- 3.11
- 3.10
- 3.9
- 3.8
- 2.17

What do you think?

Hi, sorry it took me a while to get back to you on this one.

I agree that it might be surprising to people to find tracks reverse-version-ordered when they weren't thinking of them as versions. However, as far as I know snap authors are encouraged to think of tracks in terms of versions, and telling when something is a version and isn't is really hard (openstack versions come to mind). Lastly communicating it would get really hard: "it's ordered reversed using version order unless we think it isn't a version" doesn't exactly slip off the tongue.

Given the above, I think that although reverse-version-ordered might not produce the wanted order in all cases, until we can expose ordering to publishers it remains the best option realistically available to us.

This ignores default-first-followed-by-latest as I don't see it impacting the arguments above. If I got that wrong let me know :)