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.

see: https://semver.org/#spec-item-11

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".