Version ordering seems to be alpha sorted and needs to following some kind of versioning comparison scheme

[lamont-granquist]

% curl -Ls https://willem.habitat.sh/v1/depot/pkgs/lamont-granquist/ruby |  ruby -rjson -e 'puts JSON.pretty_generate(JSON.parse(STDIN.read))'
[
  {
    "origin": "lamont-granquist",
    "name": "ruby",
    "version": "2.13.0",
    "release": "20160720180623"
  },
  {
    "origin": "lamont-granquist",
    "name": "ruby",
    "version": "2.2.5",
    "release": "20160719225821"
  },
  {
    "origin": "lamont-granquist",
    "name": "ruby",
    "version": "2.2.5",
    "release": "20160719230407"
  },
  {
    "origin": "lamont-granquist",
    "name": "ruby",
    "version": "2.2.5",
    "release": "20160719232453"
  },
  {
    "origin": "lamont-granquist",
    "name": "ruby",
    "version": "2.3.1",
    "release": "20160713205157"
  },
  {
    "origin": "lamont-granquist",
    "name": "ruby",
    "version": "2.3.1",
    "release": "20160719184108"
  },
  {
    "origin": "lamont-granquist",
    "name": "ruby",
    "version": "2.4.0-preview1",
    "release": "20160719225115"
  },
  {
    "origin": "lamont-granquist",
    "name": "ruby",
    "version": "2.4.0-preview1",
    "release": "20160719231024"
  }
]

My understanding is that version sorting is server-side and last-entry-wins on client-side.

2.13.0 should be sorted higher than 2.4.x, 2.3.x, 2.2.x, etc.

This, of course, generates a huge problem over what version sort order to use, which is a fairly open ended question with no clear solution.

At some point winners and losers likely need to get picked.

In an ideal world it would be nice to be able to tweak the version sorting scheme on a package-by-package basis since one-size-fits-all does inevitably generate losers here.

[lamont-granquist]

Things to consider off the top of my head:

Variable number of versions:

1.2 > 1.1.2
2 > 1.2.3.4

Rubygems prereleases:

2.3.1 > 2.3.1.alpha4

SemVer prereleases:

2.3.1 > 2.3.1-alpha4

RPM epochs:

12:0.1.2 > 2:1.2.3
1:2.3 > 4.5

Openssl:

1.0.1g > 1.0.1a

[lamont-granquist]

Just using semantic versioning is also already broken since openssl is already in the depot:

% curl -Ls https://willem.habitat.sh/v1/depot/pkgs/core/openssl |  ruby -rjson -e 'puts JSON.pretty_generate(JSON.parse(STDIN.read))'
[
  {
    "origin": "core",
    "name": "openssl",
    "version": "1.0.2h",
    "release": "20160612081127"
  },
  {
    "origin": "core",
    "name": "openssl",
    "version": "1.0.2h",
    "release": "20160629200645"
  },
  {
    "origin": "core",
    "name": "openssl",
    "version": "1.0.2h",
    "release": "20160630144843"
  },
  {
    "origin": "core",
    "name": "openssl",
    "version": "1.0.2h",
    "release": "20160708160802"
  }
]

[reset]

@lamont-granquist the results of the API are actually not gauranteed to be sorted but they are close enough that we could make some changes and add that gaurantee. As you point out, the identifiers are lexographically sorted which mostly gets us there but doesn't work for every versioning schema.

I don't think the web client does any additional sorting so this is probably both a bug and a feature add

[lamont-granquist]

Ah, I see there's also a "latest" route:

% curl -Ls https://willem.habitat.sh/v1/depot/pkgs/lamont-granquist/ruby/latest |  ruby -rjson -e 'puts JSON.parse(STDIN.read)["ident"]["version"]'
2.4.0-preview1

So really this bug applies to that endpoint more than the sort order of the JSON output (or both, possibly)

[reset]

@lamont-granquist yeah it applies to that endpoint as well!

[smith]

We can probably sort them with https://github.com/steveklabnik/semver

[reset]

@smith unfortunately the version piece of our package-ident doesn't enforce semver, its just the version of the software. I think we need a graceful way to:

1. Assign a versioning schema to a package scoped to origin/name
2. Disallow versioning schema changes for a package scoped to origin/name
3. Provide common versioning schemas to select
4. Bonus round: allow packages to define a custom versioning schema with instructions on how to sort it

[smith]

I'm not suggesting we force semver, just use the comparison algorithm in that package to sort the versions.

[reset]

@smith I agree with you, the items below my first reply outline the feature to remedy this problem. It probably needs a bit more discussion as to how we'll best let people specify a comparison algorithm ;)

[lamont-granquist]

We'll also need this client-side so that the hab binary can determine what the latest version of origin/pkg is installed as well (which it'll need to do)

[juliandunn]

The depot now versions packages correctly so that, for example, 0.10.0 is greater than 0.9.3.

[lamont-granquist]

can we get a link to the PR that implemented it?

[raskchanky]

@lamont-granquist I believe it was #1221