The problem is that "4.0" sorts before "4.0-alpha.1". Not saying that 3.99 is better, but something's gotta give.
back
2 comments
If you're lexicographically sorting, maybe? But if you're doing that, 3.10 and 3.2 won't sort correctly, either.
Nah, this was never really about lexicographic sorting. Pre-semver, there was general consensus between systems like dpkg and RPM about how version numbers worked. This is a bit of a simplification, but it roughly works out like this:
* Split version number into version numbers separated by non-alphanumeric components (e.g., 3.10.2 becomes (3,10,2) and 3.2 becomes (3,2)).
* Compare two versions item by item numerically (in this case, 3==3 but 10 > 2 so 3.10.2 is newer than 3.2).
This is a massive oversimplification, and if you're curious you can read more at https://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComp... for the gory details.
Source: long ago I worked at a company named Ximian that shipped a software update product that worked on systems using both RPM and dpkg, and I had to deeply understand this problem space.
Ha ha. waves
I suspect they're referring to the semver sorting rules as written in the spec:
> When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version:
> Example: 1.0.0-alpha < 1.0.0.
You can write a locale for LC_COLLATE to make pretty much anything sort any way you'd like :) http://www.unicode.org/reports/tr10/
Semantic sorting has existed for a long time. GNU coreutils have been able to do a "version sort" for years (eg, "ls -v" or "sort -V"), using the Debian rules which also happen to be a superset of semver. "4.0~alpha.1" sorts before "4.0".