Perl specifically differentiates between/supports both floating point versions and those which are integers separated by periods (TIMTOWTDI, after all). The latter is exactly what the `v`-prefix designates, and the `version` docs explicitly warn against using that form unless there are at least 3 components:
> NOTE you can technically use a v-string or strings with a leading-v and only one decimal point (v1.2 or "v1.2"), but you will confuse both yourself and others.
Yet every example of Gentoo's in TFA has only one decimal point. One might argue they seem to have confused both themselves and others.
I suppose you could argue many things? I would not naively expect Perl's versioning behavior, and a system package manager will have many users who are not Perl devs but who may nevertheless have Perl packages installed on their machines. "There is more than one way to do it" is fine for some things, but I also think it's desirable behavior for a system package manager to only require users to learn a single versioning scheme. In gentoo's case (and in most cases of system package managers I've seen), this happens to be dot-separated sequence of numbers, not floating point.
A system package manager also needs to be able to compare versions, and within gentoo's dot-separated versioning scheme 1.2 < 1.12. However, a perl package could have a dev sequence of 1.1, 1.12, 1.2. If these versions are entered naively into the gentoo packaging scheme, the intended order will not be preserved. So there must be some conversion in order to handle it correctly.
Well, for sure it's a mistake to naively expect _anything_ from Perl, of all languages!
I mean, even v-strings themselves ... despite being called version strings, they're different from `version` objects/declarations, and can be used in ways I expect most non-Perl devs might consider unexpected, for example if you run this:
It turns out[1] that v-strings are strings. So v102.111.111 is a three-character string containing codepoints decimal 102 (f), 111 (o), 111 (o), and v128513 is a one-character string containing codepoint decimal 128513 (U+1F601 GRINNING FACE WITH SMILING EYES).
... Yeah, I don’t know who thought this was a good idea either. I mean, I know versions sort lexicographically and strings do too, but no.
Bonus points:
> If there are two or more dots in the literal, the leading v may be omitted.
So 1 and 1.1 denote numbers, but 1.1.1 and 1.1.1.1 denote strings. I guess there’s a sort of syntactic pun to be had with IPv4 addresses. Still, no.
Bonus bonus points:
> Note that since Perl 5.8.1 the single-number v-strings (like v65) are not v-strings before the => operator (which is usually used to separate a hash key from a hash value); instead they are interpreted as literal strings ('v65').
So v1 always denotes a string, but which string it denotes is context-dependent.
Well... my understanding has always been that 1.1 == 1.1.0 but 1.1 != 1.10; i.e. these aren't supposed to be interpreted in the decimal sense. Declaring 1.1 == 1.10 would be very confusing to me but I understand I might be biased.
Also, I wish everyone settled on SEVMER already. There are some bizarre versioning schemes out there. I get that sometimes those are needed but do we really need the likes of Cisco versions?
Not a huge fan, except in situations mentioned in "When to use calver" from your link. However... I'm sure we can all agree that anything is better than the Mozilla/Google "major versions are now minor" arms race, that are now up to absurd numbers. Except for projects using code names. Is Wonky Wallaby more recent than Halfbaked Hamster? Fuck knows. Debian has been especially annoying with this, since the last three releases were b-words: buster, bullseye, bookworm. I can never remember. Please stop.
I wouldn't knowingly start large projects in it, but I use it all the time for projects that can be done in a few days, or at most weeks.
I learned it when I became a manager and no longer had time for real programming but still needed to automate stuff. I stepped down to become a real programmer again but I'm ever grateful for learning Perl. It's incredibly productive.
You will probably find a bunch of random scripts in various places. A lot of random system admin stuff got written in Perl, and those stick around for a long time. There is also a ton of miscellaneous software tooling that got written in Perl, like scripts to generate some C code that you compile.
Perl sometimes still gets used because it’s available on systems that don’t have Python.
Perl is much better at text processing than Python. I reach straight for Perl when solutions using grep, sed, awk, cut and tr gets weird. And I'm saying this as someone with two decades of experience in Python and next to nothing about Perl.
sort -V works the same way (1.10 > 1.9 > 1.1), as does every package manager I've ever used. Using floats for version numbers is just as insane as using them for financial transactions, but that's classic Perl for you (bonkers in their own unique way, with an optional sane system that exists in parallel which then lets you create even more bugs by confusing them).
This is what I thought for a long time too. I think this comes from things like Windows 3.1 which was called "three point one". In my mind it was like "slightly more than three", which makes sense under the "decimal" interpretation. I didn't really notice when things changed to schemes like semantic versioning, but started to get confused when the numbers to the right of the point got bigger than 9.
Nowadays I have taught myself to say "three dot one" instead to avoid confusion and stop my brain thinking these are numbers.
Windows has always had its own versioning conventions: historically it was a one-digit major and a two-digit minor, so windows 2.1 was 2.10 in full (its predecessor was 2.03, and it was followed by 2.11), and NT 3.5 was followed by NT 3.51.
This scheme was moved away from with Windows 10, which switched to a year/month versioning scheme (so the first W10 update was version 1511, as it was released in November 2015), then to the current "halves" system.
Yeah, in my mind, 3.11 > 3.1 as well, because I consider 3.1 to be 3.10 in this case. If they stick to only 3.0, 3.1, etc. then 3.2 would have been the next logical step, so I assume 3.11 is a minor version increment.
What software do you use that follows this convention? I can't think of any (as a trivial example, Linux 3.10 and 3.11 were released several years after 3.1, and after Linux 3.9).
Every package manager I've ever used works the same way too. For projects that use SemVer, this is even explicitly standardised.
Seems like we are all over the place. If you ignore the rest of my message (me considering it 3.10, which is not always the case, in retrospect), would you say "3.11 > 3.1" is false?
GNU version just uses "strverscmp()" ("sort -V" probably uses it). See the man page, it includes an example that shows you this output.
Which means what I said is correct, just not for the reasons I have provided, because I incorrectly said that I perceive "3.1" to be identical to "3.10", because they are not identical (although they could be in some cases).
This statement of mine is also incorrect: "I assume 3.11 is a minor version increment.", but it depends really. 3.11 should be greater than 3.2, not the other way.
So, most projects and package managers do it the way I correctly said (if we ignore the rest of my message), not the way Perl does it.
Ireland, Malta, and Cypress use the Euro as their currency but use dot as their decimal separator so without further context €50.000 is ambiguous.
Probably the best way to handle this is the way SI recommends dot vs comma be handled in scientific and technical writing. Their recommendation is to use a thin space for grouping, so if you see a dot or comma it is the decimal separator.
€50.000 and €50,000 would then both be exactly €50. If you meant €50000 and wanted to separate the thousands you would would write €50 000 (which looks ugly on HN because HN turns thin space into regular space).
Update: actually, SI used to recommend thin space. Now they just say space without saying what kind of space. Some people recommend choosing narrow non-breaking space (U+202F) (which HN also turns into regular space).
Also, for 4 digit numbers before the decimal they recommend not separating them, so 5k Euros would be €5000 not €5 000.
50.000 EUR is exactly 50 EUR, though. 50,000 EUR is not.
For the record, before you down-vote, check the other comments. I am from an European country where we "officially" use "," as the decimal point (so yes, I know it might not be universally true, at least not in theory), yet my bank uses ".", and so do people (many, at least). In IT, it always has been ".", too. Of course in elementary school (>20 years ago) we used "," as the decimal point, FWIW. :P It might still be the practice there.
I know, I live in such an European country, but I still know (and use) "." as the decimal point. Most people I know here do, too, and they are not in IT. I think it often depends on context, too, and I would like to think people just know.
I just checked, my bank uses "." as the decimal point, too, instead of the official ",".
I get that people can be flexible about understanding that `.` and `,` do not have a stable definition especially in an international world, but I would have thought that 50.000 EUR in context would clearly be 50 thousand. Who specifies cents with 3 digits?
I have seen it in many different places. At some I had to figure out what they really meant.
My bank is inconsistent, by the way. It uses "1234.00" where the last "00" is the cents. It was "1.234" in the same SMS. In another message (same bank) it uses "12,34". Weird. Although in the last case it might be because it is EUR, not HUF, but they are still very inconsistent.
If you turn on localization on your PC, it will use "," instead of "." (in MS Word, definitely) for decimal points though, but as I was saying, in practice (and in real life), "." seems to be the common standard still for the decimal point, it seems, even though officially it is not.
> Hungary uses a comma (",") as the decimal separator, not a period ("."). In Hungarian, a comma is used to separate the fractional part of a number from the whole part, while a period or space is used to group digits in thousands. For example, "one and a half" would be written as 1,5 in Hungarian.
Real life would beg to differ, however. My bank uses "." instead of ",", and I have had the same experience elsewhere, too. In IT, it has always been ".", too.
It is all over the place (pretty inconsistent), but I just checked my appointments to physiotherapy (printed on paper). The format is "YYYY.MM.DD", close enough. :D
From what I recall, I see this format a lot. That, and "%Y. %B|%b. %d". The latter may be the most common? I am not entirely sure. I do not mind these two formats. I have an issue with formats like 2025/05/09 and the like. Is it May, or September? It is ambiguous. Thankfully they are not common here, AFAIK.
See, this is why Canada (being a bilingual country) tried really hard to make "use spaces as the thousands separator" a thing. I mean it didn't catch on but they tried.
It's was a while since I used perl but AFAIR version you see in package versions and in `perl -v` (e. g. v5.34.1) behave like versions for most other apps, nothing to complain about if you don't complain about versions like vA.B.C.
If you want to get a version which can be sorted by number you need to use:
I was very confused the first time I encountered the x.y notation because I was wondering why version 1.15 was more recent than version 1.9... but now I'm used to it, even if I still find it very stupid, and I would be as confused when seeing a version 1.9 more recent than a 1.15
Same as wow. It makes more sense like this. Maybe the issue is that some interpret what look like decimal numbers but are not decimal numbers as decimal numbers.
Just speculating. They may be treating versions like decimal fractions. Thus, 7.16 < 7.2. But I can't say that this is the best place to use that concept.
In Python, there's no requirement that package versions follow the major.minor.patch scheme... Couple years ago the world discovered that one of the packages critical to virtually every Python project on Earth (crypto-something? I forgot what exactly that was) had this same idea about versions: use floating point numbers.
It was a mini-2000 for a day or two. A lot of CI pipelines broke.
Even after they were told that they made a mess, they still didn't do it right, and had to continue doing it in their own unnecessarily unique way. Sigh
The cryptography package is very popular, but "critical to virtually every Python project on Earth" is massive overstatement. It's not even in the top 20 most downloaded from PyPI (https://pypistats.org/top). I've never used it, while I've used Numpy many times.
The new scheme is fine. They are correct to describe it as semver-compatible — they assess that every time they add functionality it is backwards-incompatible, and their backwards-compatible changes are inherently just bugfixes. And they are correct that Firefox version numbers have been doing the same thing, and thus their way is not unique.
The old cryptography version numbers were not "floating point numbers" (as demonstrated by the fact that they often had two decimal points). They were just incorrectly using the major and minor parts of a version number to communicate what changed between releases. They weren't doing anything like expecting version 1.11 to be treated as older than version 1.2. I can't fathom how this is supposed to have broken CI pipelines.
I think this package is, basically, a requirement for anything Web-related in Python, but also stuff like SSH (so Paramico? or similar? Didn't look if they depend on it). So, also stuff like Ansible... well, anything that needs to authenticate using cryptographic protocols.
You don't have to be the most popular to break every CI in the world. If you are only responsible for authentication, it's enough to break all CI in the world :)
> To make matters interesting, a leading v on a Perl version, or the presence of 2 or more .'s imply a sort order closer to Gentoos.
This is 100% classic perl: the default is bonkers and unintuitive, but the behaviour also changes in a DWIM manner to throw people off. And of course there are two different ways to represent versions so simply forgetting the v (one character) can cause a litany of bugs.
Perl specifically differentiates between/supports both floating point versions and those which are integers separated by periods (TIMTOWTDI, after all). The latter is exactly what the `v`-prefix designates, and the `version` docs explicitly warn against using that form unless there are at least 3 components:
> NOTE you can technically use a v-string or strings with a leading-v and only one decimal point (v1.2 or "v1.2"), but you will confuse both yourself and others.
Yet every example of Gentoo's in TFA has only one decimal point. One might argue they seem to have confused both themselves and others.
I suppose you could argue many things? I would not naively expect Perl's versioning behavior, and a system package manager will have many users who are not Perl devs but who may nevertheless have Perl packages installed on their machines. "There is more than one way to do it" is fine for some things, but I also think it's desirable behavior for a system package manager to only require users to learn a single versioning scheme. In gentoo's case (and in most cases of system package managers I've seen), this happens to be dot-separated sequence of numbers, not floating point.
A system package manager also needs to be able to compare versions, and within gentoo's dot-separated versioning scheme 1.2 < 1.12. However, a perl package could have a dev sequence of 1.1, 1.12, 1.2. If these versions are entered naively into the gentoo packaging scheme, the intended order will not be preserved. So there must be some conversion in order to handle it correctly.
Well, for sure it's a mistake to naively expect _anything_ from Perl, of all languages!
I mean, even v-strings themselves ... despite being called version strings, they're different from `version` objects/declarations, and can be used in ways I expect most non-Perl devs might consider unexpected, for example if you run this:
lol what?
For those without perl readily accessible to them, 'v102.111.111' becomes 'foo' and 'v128513' gives you a smiley emoji.
I'm not sure I even want to know.
It turns out[1] that v-strings are strings. So v102.111.111 is a three-character string containing codepoints decimal 102 (f), 111 (o), 111 (o), and v128513 is a one-character string containing codepoint decimal 128513 (U+1F601 GRINNING FACE WITH SMILING EYES).
... Yeah, I don’t know who thought this was a good idea either. I mean, I know versions sort lexicographically and strings do too, but no.
Bonus points:
> If there are two or more dots in the literal, the leading v may be omitted.
So 1 and 1.1 denote numbers, but 1.1.1 and 1.1.1.1 denote strings. I guess there’s a sort of syntactic pun to be had with IPv4 addresses. Still, no.
Bonus bonus points:
> Note that since Perl 5.8.1 the single-number v-strings (like v65) are not v-strings before the => operator (which is usually used to separate a hash key from a hash value); instead they are interpreted as literal strings ('v65').
So v1 always denotes a string, but which string it denotes is context-dependent.
[1] https://perldoc.perl.org/perldata#Version-Strings
I use to love writing Perl. It's great fun to create! But this is exemplary of the reasons I abandoned it in the late 90s.
It's not so much weakly typed as randomly typed.
Which part? The fact that bare words are taken as literal strings before => is one of the very features of => and not random at all.
Likewise, 1.1.1 doesn't have a sensible interpretation as a number, so surely it must be a version? Hardly random.
And Gentoo aren't alone: https://metacpan.org/dist/DBIx-Class/source/lib/DBIx/Class.p...
Well... my understanding has always been that 1.1 == 1.1.0 but 1.1 != 1.10; i.e. these aren't supposed to be interpreted in the decimal sense. Declaring 1.1 == 1.10 would be very confusing to me but I understand I might be biased.
Also, I wish everyone settled on SEVMER already. There are some bizarre versioning schemes out there. I get that sometimes those are needed but do we really need the likes of Cisco versions?
Pretty fond of calendar versioning as of late myself. [0]
[0] https://calver.org
Not a huge fan, except in situations mentioned in "When to use calver" from your link. However... I'm sure we can all agree that anything is better than the Mozilla/Google "major versions are now minor" arms race, that are now up to absurd numbers. Except for projects using code names. Is Wonky Wallaby more recent than Halfbaked Hamster? Fuck knows. Debian has been especially annoying with this, since the last three releases were b-words: buster, bullseye, bookworm. I can never remember. Please stop.
Perl would be never bizarre or confusing
Where is perl being used today? I imagine it has a diehard community, but it's not very publicly visible these days.
I wouldn't knowingly start large projects in it, but I use it all the time for projects that can be done in a few days, or at most weeks.
I learned it when I became a manager and no longer had time for real programming but still needed to automate stuff. I stepped down to become a real programmer again but I'm ever grateful for learning Perl. It's incredibly productive.
If you have a Linux system, try this:
You will probably find a bunch of random scripts in various places. A lot of random system admin stuff got written in Perl, and those stick around for a long time. There is also a ton of miscellaneous software tooling that got written in Perl, like scripts to generate some C code that you compile.Perl sometimes still gets used because it’s available on systems that don’t have Python.
Perl is much better at text processing than Python. I reach straight for Perl when solutions using grep, sed, awk, cut and tr gets weird. And I'm saying this as someone with two decades of experience in Python and next to nothing about Perl.
Viznut uses perl to build the fonts from source in Unscii.
* https://github.com/jdebp/unscii/tree/2.1.1f
Unless it's changed recently, the control center apps in Mandrake descendants is in Perl.
I'm pretty sure they use it heavily at DuckDuckGo. Possibly also Cloudflare?
Yup. We still do (at DuckDuckGo), though now also alongside a bunch of other languages.
I use it a lot for ETL.
In comparison with Logstash, for example, it is much more flexible and the scripts are simpler and shorter.
I believe Booking.com uses a lot of Perl.
Craigslist
In my mind, it is:
as well.In my mind, these are not decimal numbers, these are version, subversion(, revision), so 1.10 comes after 1.9
EDIT: I'm also reminded of after minecraft 1.9 came out, everyone going "does that mean that minecraft 2.0 is next?" like no, its 1.10 next
I see where you are coming from.
I would check what GNU's vercmp and Arch's vercmp would say, but I have no access to them right now.
Only got access to the Arch version.
Same for me (vercmp v6.0.2, Ubuntu 24.04.2)
sort -V works the same way (1.10 > 1.9 > 1.1), as does every package manager I've ever used. Using floats for version numbers is just as insane as using them for financial transactions, but that's classic Perl for you (bonkers in their own unique way, with an optional sane system that exists in parallel which then lets you create even more bugs by confusing them).
This is what I thought for a long time too. I think this comes from things like Windows 3.1 which was called "three point one". In my mind it was like "slightly more than three", which makes sense under the "decimal" interpretation. I didn't really notice when things changed to schemes like semantic versioning, but started to get confused when the numbers to the right of the point got bigger than 9.
Nowadays I have taught myself to say "three dot one" instead to avoid confusion and stop my brain thinking these are numbers.
Windows has always had its own versioning conventions: historically it was a one-digit major and a two-digit minor, so windows 2.1 was 2.10 in full (its predecessor was 2.03, and it was followed by 2.11), and NT 3.5 was followed by NT 3.51.
This scheme was moved away from with Windows 10, which switched to a year/month versioning scheme (so the first W10 update was version 1511, as it was released in November 2015), then to the current "halves" system.
There was also a minor upgrade to Windows 3.1 called Windows 3.11, which further reinforces your point.
Yeah, in my mind, 3.11 > 3.1 as well, because I consider 3.1 to be 3.10 in this case. If they stick to only 3.0, 3.1, etc. then 3.2 would have been the next logical step, so I assume 3.11 is a minor version increment.
What software do you use that follows this convention? I can't think of any (as a trivial example, Linux 3.10 and 3.11 were released several years after 3.1, and after Linux 3.9).
Every package manager I've ever used works the same way too. For projects that use SemVer, this is even explicitly standardised.
Seems like we are all over the place. If you ignore the rest of my message (me considering it 3.10, which is not always the case, in retrospect), would you say "3.11 > 3.1" is false?
Because according to "vercmp", it is true: https://news.ycombinator.com/item?id=44634420.
GNU version just uses "strverscmp()" ("sort -V" probably uses it). See the man page, it includes an example that shows you this output.Which means what I said is correct, just not for the reasons I have provided, because I incorrectly said that I perceive "3.1" to be identical to "3.10", because they are not identical (although they could be in some cases).
This statement of mine is also incorrect: "I assume 3.11 is a minor version increment.", but it depends really. 3.11 should be greater than 3.2, not the other way.So, most projects and package managers do it the way I correctly said (if we ignore the rest of my message), not the way Perl does it.
By the way:
Arch Linux's is expected, as "05 < 10", but "strverscmp()" interprets "1.05" as "1.5". That said, neither of the two are Perl-style.I'd agree that 3.11 > 3.1 whether we're considering it a version, a float, or a string.
I agree.
These look like decimal numbers because they use a period-delimiter, but they are not, in the same way that €50.000 is not €50...
Ireland, Malta, and Cypress use the Euro as their currency but use dot as their decimal separator so without further context €50.000 is ambiguous.
Probably the best way to handle this is the way SI recommends dot vs comma be handled in scientific and technical writing. Their recommendation is to use a thin space for grouping, so if you see a dot or comma it is the decimal separator.
€50.000 and €50,000 would then both be exactly €50. If you meant €50000 and wanted to separate the thousands you would would write €50 000 (which looks ugly on HN because HN turns thin space into regular space).
Update: actually, SI used to recommend thin space. Now they just say space without saying what kind of space. Some people recommend choosing narrow non-breaking space (U+202F) (which HN also turns into regular space).
Also, for 4 digit numbers before the decimal they recommend not separating them, so 5k Euros would be €5000 not €5 000.
I need to make an urgent call to my accountant.
50.000 EUR is exactly 50 EUR, though. 50,000 EUR is not.
For the record, before you down-vote, check the other comments. I am from an European country where we "officially" use "," as the decimal point (so yes, I know it might not be universally true, at least not in theory), yet my bank uses ".", and so do people (many, at least). In IT, it always has been ".", too. Of course in elementary school (>20 years ago) we used "," as the decimal point, FWIW. :P It might still be the practice there.
Most European countries use . as the thousands separator and , as the decimal point.
I know, I live in such an European country, but I still know (and use) "." as the decimal point. Most people I know here do, too, and they are not in IT. I think it often depends on context, too, and I would like to think people just know.
I just checked, my bank uses "." as the decimal point, too, instead of the official ",".
> I think it often depends on context, too
I get that people can be flexible about understanding that `.` and `,` do not have a stable definition especially in an international world, but I would have thought that 50.000 EUR in context would clearly be 50 thousand. Who specifies cents with 3 digits?
I have seen it in many different places. At some I had to figure out what they really meant.
My bank is inconsistent, by the way. It uses "1234.00" where the last "00" is the cents. It was "1.234" in the same SMS. In another message (same bank) it uses "12,34". Weird. Although in the last case it might be because it is EUR, not HUF, but they are still very inconsistent.
Hah - there I go acting like I know more about Europe than a European. TIL!
Let me guess: Ireland or Malta? If not, then Germany?
Hungary. Would have you ever guessed? :P
If you turn on localization on your PC, it will use "," instead of "." (in MS Word, definitely) for decimal points though, but as I was saying, in practice (and in real life), "." seems to be the common standard still for the decimal point, it seems, even though officially it is not.
> Hungary uses a comma (",") as the decimal separator, not a period ("."). In Hungarian, a comma is used to separate the fractional part of a number from the whole part, while a period or space is used to group digits in thousands. For example, "one and a half" would be written as 1,5 in Hungarian.
Real life would beg to differ, however. My bank uses "." instead of ",", and I have had the same experience elsewhere, too. In IT, it has always been ".", too.
Interesting! I wouldn't have guessed, my next candidate would have been the Netherlands.
How is ISO date (2025-07-21) adoption in Hungary?
It is all over the place (pretty inconsistent), but I just checked my appointments to physiotherapy (printed on paper). The format is "YYYY.MM.DD", close enough. :D
From what I recall, I see this format a lot. That, and "%Y. %B|%b. %d". The latter may be the most common? I am not entirely sure. I do not mind these two formats. I have an issue with formats like 2025/05/09 and the like. Is it May, or September? It is ambiguous. Thankfully they are not common here, AFAIK.
Depends on what language you speak. Having gotten used to commas as decimal separators, semantic versions never were that confusing to me.
See, this is why Canada (being a bilingual country) tried really hard to make "use spaces as the thousands separator" a thing. I mean it didn't catch on but they tried.
It's was a while since I used perl but AFAIR version you see in package versions and in `perl -v` (e. g. v5.34.1) behave like versions for most other apps, nothing to complain about if you don't complain about versions like vA.B.C.
If you want to get a version which can be sorted by number you need to use:
I was very confused the first time I encountered the x.y notation because I was wondering why version 1.15 was more recent than version 1.9... but now I'm used to it, even if I still find it very stupid, and I would be as confused when seeing a version 1.9 more recent than a 1.15
You'd love Final Fantasy 14's versioning scheme. Here's the most recent patches in order:
* 7.0: the expansion Dawntrail
* 7.1: Crossroads, a post-expansion story/content patch
* 7.11: A new ultimate raid
* 7.15: More side content and the first chaotic alliance raid
* 7.16: More role quests
* 7.2: Seekers of Eternity story quests and more Arcadion normal raids (Cruiserweight)
* 7.21: Cosmic Exploration (crafter/gatherer power leveling area)
* 7.25: Occult Crescent (field operation)
* 7.3: The Promise of Tomorrow story quests (slated to come out early next month)
This version progression breaks my brain because I am very used to semantic versioning.
Same as wow. It makes more sense like this. Maybe the issue is that some interpret what look like decimal numbers but are not decimal numbers as decimal numbers.
Am I parsing this right? Are we adding a place to the version number to denote 'this change is in the 2s'?
So we went from v0 to v10, then to v11, then v15, and so on?
Just speculating. They may be treating versions like decimal fractions. Thus, 7.16 < 7.2. But I can't say that this is the best place to use that concept.
Let's hope Perl version floats don't ever have more than 6 decimal places. That's important for the normalization to work.
GenWHO?
God I hate perl...
In Python, there's no requirement that package versions follow the major.minor.patch scheme... Couple years ago the world discovered that one of the packages critical to virtually every Python project on Earth (crypto-something? I forgot what exactly that was) had this same idea about versions: use floating point numbers.
It was a mini-2000 for a day or two. A lot of CI pipelines broke.
----
Oh, yeah, I found them. My heroes: https://cryptography.io/en/latest/api-stability/#versioning
Even after they were told that they made a mess, they still didn't do it right, and had to continue doing it in their own unnecessarily unique way. Sigh
The cryptography package is very popular, but "critical to virtually every Python project on Earth" is massive overstatement. It's not even in the top 20 most downloaded from PyPI (https://pypistats.org/top). I've never used it, while I've used Numpy many times.
The new scheme is fine. They are correct to describe it as semver-compatible — they assess that every time they add functionality it is backwards-incompatible, and their backwards-compatible changes are inherently just bugfixes. And they are correct that Firefox version numbers have been doing the same thing, and thus their way is not unique.
The old cryptography version numbers were not "floating point numbers" (as demonstrated by the fact that they often had two decimal points). They were just incorrectly using the major and minor parts of a version number to communicate what changed between releases. They weren't doing anything like expecting version 1.11 to be treated as older than version 1.2. I can't fathom how this is supposed to have broken CI pipelines.
I think this package is, basically, a requirement for anything Web-related in Python, but also stuff like SSH (so Paramico? or similar? Didn't look if they depend on it). So, also stuff like Ansible... well, anything that needs to authenticate using cryptographic protocols.
You don't have to be the most popular to break every CI in the world. If you are only responsible for authentication, it's enough to break all CI in the world :)
Why? This isn't a Perl problem.
> To make matters interesting, a leading v on a Perl version, or the presence of 2 or more .'s imply a sort order closer to Gentoos.
This is 100% classic perl: the default is bonkers and unintuitive, but the behaviour also changes in a DWIM manner to throw people off. And of course there are two different ways to represent versions so simply forgetting the v (one character) can cause a litany of bugs.
It's so ungoogleable.
they don't know why, they only know spewing drive-by perl hate is easy upvote fodder for midwits who can't think of anything reasonable to contribute