4 ms·

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.

BiteCode_dev 3y ago
Sem ver is pretty standard imo.
Scarblac 3y ago
Like in most versioning schemes, the dot isn't meant to be read as decimal point.
rcxdude 3y ago
comparing version numbers as tuples and not as decimals is a pretty standard thing. Linux does it as well, for example. I am actually not sure of a project which does something different.
- irishsultan 3y ago
  TeX and Metafont have version numbers that are approaching pi and e respectively, so the sensible way is to read these as decimals.
throwaway468234 3y ago
Is there any versioning scheme that is comparable? Honest question.
- burkaman 3y ago
  Some languages just use integer versions, like Java.
  - fullstop 3y ago
    The early versions did not use integers, for what it's worth.
  - josefx 3y ago
    Java dropped the leading 1 with version 5 since Sun decided it would never go for a complete rewrite of the language. Imagine the chaos if Python did that and then pulled the 2 to 3 change on a run of the mill update from 213 to 214.
    - jcranmer 3y ago
      Not sure that's entirely accurate. 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.
- jorgemf 3y ago
  I think kotlin is one example. It uses the same idea but it uses powers of 10 for incremental fixes and numbers for 1 to 9 for hotfixes. That's if for the 3rd number, I do not know what will happen when the second number reaches 2 digits. I guess they will do something to make it comparable again.
- nxpnsv 3y ago
  TeX version number asymptotically approaches pi... each new version has another digit, this also makes versions comparable. Clearly this is the better way....
- deleted 3y ago
  [deleted]
- coldtea 3y ago
  Comparable as what? 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.
  - usrbinbash 3y ago
    Or I could just accept that neither numeric, nor string ordering works for semantic versioning, and write a trivially easy piece of code that does the ordering in a contect where I expect such a scheme. > 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.
    - coldtea 3y ago
      >Or I could just accept that neither numeric, nor string ordering works for semantic versioning, and write a trivially easy piece of code that does the ordering in a contect where I expect such a scheme. 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.
      - usrbinbash 3y ago
jjoonathan 3y ago
I won't argue with bizzare, but it's common in version notation. 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 :)
- coldtea 3y ago
  Is it that bizarre? 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).
Aurornis 3y ago
Semantic Versioning is ubiquitous across the modern software industry. It’s worth reading about it if you’re not familiar: https://semver.org/ https://semver.org/ 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.
- luhn 3y ago
  I know you didn't say it outright, but since it is implied: Python does not use semver, although it does share similar formatting. Semver considers bumps to the second integer a "minor" release with no breaking changes, whereas in Python that indicates a major release that is not backwards compatible.
coldtea 3y ago
You mean uncomparable using numeric or string sorting on those strings? 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").

BiteCode_dev 3y ago

Sem ver is pretty standard imo.

Scarblac 3y ago

Like in most versioning schemes, the dot isn't meant to be read as decimal point.

rcxdude 3y ago

comparing version numbers as tuples and not as decimals is a pretty standard thing. Linux does it as well, for example. I am actually not sure of a project which does something different.

irishsultan 3y ago
TeX and Metafont have version numbers that are approaching pi and e respectively, so the sensible way is to read these as decimals.

throwaway468234 3y ago

Is there any versioning scheme that is comparable? Honest question.

burkaman 3y ago
Some languages just use integer versions, like Java.
- fullstop 3y ago
  The early versions did not use integers, for what it's worth.
- josefx 3y ago
  Java dropped the leading 1 with version 5 since Sun decided it would never go for a complete rewrite of the language. Imagine the chaos if Python did that and then pulled the 2 to 3 change on a run of the mill update from 213 to 214.
  - jcranmer 3y ago
    Not sure that's entirely accurate. 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.
jorgemf 3y ago
I think kotlin is one example. It uses the same idea but it uses powers of 10 for incremental fixes and numbers for 1 to 9 for hotfixes. That's if for the 3rd number, I do not know what will happen when the second number reaches 2 digits. I guess they will do something to make it comparable again.
nxpnsv 3y ago
TeX version number asymptotically approaches pi... each new version has another digit, this also makes versions comparable. Clearly this is the better way....
deleted 3y ago
[deleted]
coldtea 3y ago
Comparable as what? 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.
- usrbinbash 3y ago
  Or I could just accept that neither numeric, nor string ordering works for semantic versioning, and write a trivially easy piece of code that does the ordering in a contect where I expect such a scheme. > 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.
  - coldtea 3y ago
    >Or I could just accept that neither numeric, nor string ordering works for semantic versioning, and write a trivially easy piece of code that does the ordering in a contect where I expect such a scheme. 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.
    - usrbinbash 3y ago

jjoonathan 3y ago

I won't argue with bizzare, but it's common in version notation. 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 :)

coldtea 3y ago
Is it that bizarre? 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).

Aurornis 3y ago

Semantic Versioning is ubiquitous across the modern software industry. It’s worth reading about it if you’re not familiar: https://semver.org/ https://semver.org/ 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.

luhn 3y ago
I know you didn't say it outright, but since it is implied: Python does not use semver, although it does share similar formatting. Semver considers bumps to the second integer a "minor" release with no breaking changes, whereas in Python that indicates a major release that is not backwards compatible.

coldtea 3y ago

You mean uncomparable using numeric or string sorting on those strings? 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").