Why does Python use an un-comparable version number scheme? Not being a Python programmer, comparing version 3.9 to 3.13 seemed bizarre until I caught on.
Never assume that version numbers are decimal values. It’s more obvious when you see the full version triple (3.13.0 for example) that it’s not a single number, but the abbreviated version numbers can some times look like a decimal value. You should never compare version numbers as decimals in modern software unless you’re absolutely sure that’s how the project is structured.
If it wasn't already common, it would probably become common shortly after the first time a big respectable company hit the "oops what comes after 9" problem and decided on dot-separated-integers rather than significant digits :)
It's basically semantic versioning, that is a hierarchical split based on levels of change (major = new release with possibly big breaking changes, minor = some incremental update version within the same release) and so on.
Who ever thought version numbers are decimals and why? The "." appears as a separator on all kinds of strings in software (filenames, domains, and IPs probably the most common ones).
Java 1.2 was branded as "Java 2", so you had the J2SE (Java 2, Standard Edition) and related J2ME and J2EE (Mobile and Enterprise, respectively) platforms. The "Java 2" moniker was dropped in Java 5, which was the largest rewrite of the language since, adding generics, sane memory model, annotations, etc., all in the same language revision.
3.10 and 3.9 are perfectly mechanically comparable (meaning one can write a program to deterministically compare them and return their relative order), just not with default numeric ordering (then again they're not numbers, they are composite values that are comprised by numbers) or naive string based ordering.
If we wanted trivially comparable with regular numeric ordering we could have incremental numbers as versions. 1, 2, 3, ...
And if we wanted string ordering (as with usual filesystem listing sorting with no extra flags to treat as numbers), we could have fixed length padded parts: 00001.00045.
Not sure if the latter is used, but some software does use the first.
> If we wanted trivially comparable with regular numeric ordering we could have incremental numbers as versions. 1, 2, 3, ...
Yes, and then we would be back to the day when the version number gave me zero information about what changed, and how that affects compatibility with existing code.
There is a reason semver is used across the industry by now.
Hence the whole "3.10 and 3.9 are perfectly mechanically comparable (meaning one can write a program to deterministically compare them and return their relative order)" part in my comment you perhaps missed.
>Yes, and then we would be back to the day when the version number gave me zero information about what changed, and how that affects compatibility with existing code.
Not that it's any better now with semver though: in practice the semver works 95% of the time, and give just a false sense of comfort at the other 5%. You update, and things still break, despite the semver promise.
I didn't miss any part of your comment. The line you quote was as a reaction to the alternatives presented immediately after that part.
Because why would I sacrifice the advantages of semver for a minor convenience to the programmer of a sorting function?
> in practice the semver works 95% of the time
Which, based on nothing but my gut feeling, is a lot better than the 30% of the time any other versioning scheme works, where the only way to be reasonably sure that an update would not break my code was to diff the library (if the thing is open source), or read all the documentation, and pray to Zeus that it's complete and accurate.
Because otherwise it's perfectly comparable - and quite common.
Most FOSS uses a variant of <major>.<minor>.<patch> (here just major (3) + minor (13), minor meaning "release within the same major Python version").