PPC: Perl version number

[ap]

What it says on the tin.

[book]

Perl authors should always declare which version of the Perl language their code is written against. We should make use VERSION the new "use strict and warnings" (i.e. common Perl knowledge). Having a whole number as the version makes that even easier.

This change is pretty much in line with similar statements made by a previous PSC in their 2022 post What happened to Perl 7?.

[guest20]

@book use warnings; use strict is advice that still works 20 years after the first line of perl I wrote ... If I'd been given that advice back then I'd still be telling people to "use five eight eight"...

I don't think a moving version number makes for a very good mantra, even if it's just a single digit...

[book]

use warnings; use strict is advice that still works 20 years after the first line of perl I wrote ... If I'd been given that advice back then I'd still be telling people to "use five eight eight"...

Starting with v5. 36, in just one line, one gets a much better Perl than use strict; use warnings; can give them.

I don't think a moving version number makes for a very good mantra, even if it's just a single digit...

It's not about running after a moving target. It's about consciously picking which version of the Perl language a given program is written in.

[happy-barney]

when touching behaviour of use VERSION rather consider change from "use at least this version of interpreter" to "use exactly this version of syntax and behaviour"

[book]

when touching behaviour of use VERSION rather consider change from "use at least this version of interpreter" to "use exactly this version of syntax and behaviour"

You mean... break backwards compatibility?

[Tux]

when touching behaviour of use VERSION rather consider change from "use at least this version of interpreter" to "use exactly this version of syntax and behaviour"

You mean... break backwards compatibility?

This is exactly what Jesse envisioned when he was Pumpkin. Interpretation and expectation also scattered then

I am in the camp of "Use this or newer", but I understand the other side

[happy-barney]

when touching behaviour of use VERSION rather consider change from "use at least this version of interpreter" to "use exactly this version of syntax and behaviour"

You mean... break backwards compatibility?

please explain why do you mean it is breaking backwards compatibility?

I'm not saying that only perl-5.12 will satisfy use v5.12, I'm saying that for example even with perl-5.40 this will become syntax error:

use v5.12;
package Foo v1.0 {
}

simply because package-version was added in v5.14

[happy-barney]

ok, this probably requires larger discussion, so I'll simply starts with some points I treat as pros:

• at long run simplifies core - maintaining grammar per version, callbacks per version, version id in XS symbols
  • allows to move "really old" versions into libraries
• allows incompatible changes (like use fields in 5.10)
• allows "forward" grammars - you should be able load newer grammar via library (and accepting related performance penalty)
  • so developer can start to use newer syntax even when production uses old binary with just newer library
• once implemented (and backported to older perls), there will be no need to address multi-version index

[book]

when touching behaviour of use VERSION rather consider change from "use at least this version of interpreter" to "use exactly this version of syntax and behaviour"

You mean... break backwards compatibility?

please explain why do you mean it is breaking backwards compatibility?

Sorry, I misread "use exactly this version of syntax and behaviour" as "accept only this version of the perl binary". Apologies.

I'm not saying that only perl-5.12 will satisfy use v5.12, I'm saying that for example even with perl-5.40 this will become syntax error:

use v5.12;
package Foo v1.0 {
}

simply because package-version was added in v5.14

This is an error:

$ perl5.40.0 -e '
use v5.12;
package Foo v1.0 {
}
'
Invalid version format (dotted-decimal versions require at least three parts) at -e line 3, near "package Foo "
syntax error at -e line 3, near "package Foo v1.0"
Execution of -e aborted due to compilation errors.        

but this isn't:

$ perl5.40.0 -e '
use v5.12;
package Foo v1.0.0 {
}
'

[ap]

@happy-barney

I'm not saying that only perl-5.12 will satisfy use v5.12, I'm saying that for example even with perl-5.40 this will become syntax error:

use v5.12;
package Foo v1.0 {
}

simply because package-version was added in v5.14

That’s not what use v5.12 means now so it cannot be imposed retroactively. It is automatically going to be true in future for anything introduced behind a feature flag. Should everything new live behind a feature flag? That’s a debate I think. There are arguments in favor of that.

However, that is a separate topic from the version of Perl.

[happy-barney]

@book I have a feeling that you didn't understand what I'm trying to say :-( ... when you say "this code runs on 5.12 or more", it must run on 5.12. ... it should fail with every perl (that will also diminish need for perl version matrix testing necessity)

[haarg]

@book I have a feeling that you didn't understand what I'm trying to say :-( ... when you say "this code runs on 5.12 or more", it must run on 5.12. ... it should fail with every perl (that will also diminish need for perl version matrix testing necessity)

This is unrelated to this PPC.

[duncand]

I fully agree that having "use 42;" is the best way to go for Perl version declarations going forward. No 5.x or 7.x etc, just X, and no "v" either. As to whether a declaration blocks use of Perl versions greater than 42 and some new syntax means 42-plus, that shouldn't be done unless something similar is supported for module versions, and that's all a separate and complicated discussion. The "use 42" should mean the same way of understanding as "use 5.040" etc does.

[oodler577]

I vote no. I remember when cPanel did this, and it was a very expensive no-op. https://en.wikipedia.org/wiki/CPanel#History, and this seems to coincide with some significance some people place on the number 42 and the upcoming opportunity the "5.42" version seems to represent; which is really stupid in the grand scheme of things. Please resist this urge to taint Perl with some odd connection to a British Sci-Fi book series a handful of people find important or cheeky for some reason.

[esabol]

I'm also not in favor of this PPC, at least in the specifics. I would be in favor of Perl's major version jumping to 7 in a near-future release, however.

[happy-barney]

unrelated to previous comments in this PR, I'd mention my earlier proposal to switch versioning. Combined with this, what about:

use v2024;

also, pros and cons, what about treating these as aliases (ie, v2025 will be an alias for v5.42 ... both will be usable

[book]

unrelated to previous comments in this PR, I'd mention my earlier proposal to switch versioning. Combined with this, what about:

use v2024;

also, pros and cons, what about treating these as aliases (ie, v2025 will be an alias for v5.42 ... both will be usable

See also Modern::Perl, which has been doing this since 2012.

[book]

this seems to coincide with some significance some people place on the number 42 and the upcoming opportunity the "5.42" version seems to represent;

42 is exactly what you describe: a coïncidence.

[book]

Quoting https://semver.org/, for those who are into it:

Semantic Versioning 2.0.0

Summary

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backward compatible manner
3. PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

And noting that all PSC have proclaimed the same thing since their inception in 2020:

• in 2022

  Existing sensibly-written Perl 5 code should continue to run under future releases of Perl.

• in 2024 (check page 6, "Future Plans for Perl")

  Don’t break things unnecessarily

I follows that:

1. We won't break Perl in the SemVer sense (or any other sense) in the foreseeable future.
2. Therefore, we don't need a MAJOR version number (PERL_REVISION in the Perl source).
3. Profit! And so, we drop the 5.

[ap]

42 is exactly what you describe: a coïncidence.

Although a lucky one, undoubtedly. 🙂

[guest20]

@Plato I'm betting a very similar thing to any other release notes - I'm guessing there's good odds the EPIGRAPH is going to be towel related

@ap I don't see "updating the release email template" listed under "## Open Issues"

[ap]

@guest20 Good catch, thanks. (There doesn’t seem to be much to figure out there, other than to just do it, so it goes straight into the Specification instead, but same difference.)

[book]

But, as long as the use VERSION line at the top of the file matches the version of the Perl language that the author meant, perl5.40.0 will run the code exactly as expected.

@book: This simply is not true.

@briandfoy: You are, of course, absolutely right: I was lying when I said feature was magical. 😅

I noted it myself, when I mentioned the autoderef feature. Not every new Perl feature is guarded by a feature (see Syntax::Construct for an extensive list).

In both our examples, though, the troublesome construction was experimental when it was introduced, and it was removed without having ever left the experimental state. I'm not convinced that code that uses experimental constructs falls under the definition of "sensibly-written" (as written by the 2021-2022 PSC in What happened to Perl 7?).

Nowadays, p5p would not introduce a change of meaning or behaviour in valid syntax without a feature guard (for an example, see the bitwise feature, which changed the meaning of the binary operators). See also how the removal of deprecated features is handled, most recently with the apostrophe_as_package_separator feature.

We're aiming for a future where most of the old ("sensibly-written") code will continue to work, untouched, with the latest perl, while everyone can write better Perl by pointedly picking the best use VERSION; line for their use case.

My message was driven by my enthusiasm for use VERSION itself. No matter if this PPC goes through or not, we want to make use VERSION the staple of modern Perl code. Yes, Perl is incredibly backwards-compatible. As we've seen, though, that's not always 100% foolproof. use VERSION is still the best hint a programmer can give to their language interpreter/compiler to ensure everything will work as expected, for as long as possible.

One of the points of this PPC (besides "Perl 5 is Perl" and "there is no successor to Perl"), is that use 42; is much more readable (and less error-prone) than use v5.42; or use 5.042;.

[iabyn]

On Fri, Nov 22, 2024 at 04:54:10AM -0800, Graham Knop wrote: > I _LOATHE_ this proposal. Can you elaborate at all?

There are two sides to this issue: technical and marketing. From the marketing side, I think that changing the versioning scheme will have exactly 0.0000% impact on slowing the gradual decline of perl. Most people outside the perl sphere wont notice or care, and the few who do notice will (correctly) assume that this is just a cynical marketing ploy. From the technical side, there are no benefits. There are definite downsides however. Perl versioning is very visible to the language, e.g. use v5.40; if ($] > 5.020_001) { ... } #if PERL_REVISION == 5 && PERL_VERSION >= 6 etc, and the version can be expressed in lots of different ways, as shown in the examples above. Changes to the scheme just increases the cognitive load. We've only recently reached the point where we no longer have to worry much about version 5.005_03 being a thing, and the transition to 5.6.0 was 25 years ago. Consider: do people know off the top of their heads what each of the following do: use v5.40; use v5.40.0; use v5.040000; use v5.040_000; use 5.40; use 5.40.0; use 5.040000; use 5.040_000; I certainly don't. Why add further confusion for apparently zero gain? I remember when Sun decided that SunOS 5.x would be branded as Solaris 2.x; then they decided that Solaris 2.y would be rebranded as 'Solaris y', but under the hood, uname etc would tell you it was 'SunOS 5.y'.

…

-- A power surge on the Bridge is rapidly and correctly diagnosed as a faulty capacitor by the highly-trained and competent engineering staff. -- Things That Never Happen in "Star Trek" #9

[guest20]

Paraphrasing @iabyn

v-strings, version.pm, feature bundles and _ in numbers, oh my!

It's definitely worth brushing up on those things† in a discussion about those things. I know I had to.

Why add further confusion for apparently zero gain?

With a two part version there is no need for the super confusing v-string binary-packed decimal notation in the first place, and since 42.1 fits into a regular old number we no longer need version.pm to make things comparable via overload jank.

With two part versions most of the things that make you uneasy about those version declarations magically go away‡, and that sounds like a pretty major gain to me.

Now we can compare numbers like the Arabic scholars of old intended.

if ($] > 5.020_001) { ... }
#if PERL_REVISION == 5 && PERL_VERSION >= 6

This is covered in the PPC under "Backwards Compatibility".

I can't see the rest of this hypothetical code, but I'm betting it's an early return using some feature from newer perl in the positive case, and some ancient jank in the fall-through case. 42 being greater than 5.020_001 seems to preserve those semantics pretty well.

I will have to admit a weakness at this point and admit that although it does sound unnerving that int $] and PERL_REVISION might not be equal but I really don't do enough XS to be upset by that. I don't even know how to access $] in XS⸸

__
†.
https://xdg.me/version-numbers-should-be-boring/
https://perldoc.perl.org/feature#FEATURE-BUNDLES
https://perldoc.perl.org/perldata#Version-Strings
‡. ... except _, which really feels like it's being dragged into this against its will
⸸. ... is it macros? I bet it's macros

[leonerd]

On the subject of the v-string numbers specifically: I might be in the minority, but I actually like the leading v.

If you look at the start of a file and you see

use v5.36;

you probably have some idea that Perl version 5.36 is a thing. And that leading v gives more of a hint here as to what's going on. "version 5.36", yes that sounds like a related thing here.

use 42;

What's this number doing here? I get no clue as to what's going on.

Whatever actual number(s) we decide on in future, at the very least I suggest we keep that leading v in all the examples and suggested "here's how you should write your code", because it is actually useful.

[ap]

@iabyn

Thanks for elaborating.

Changes to the scheme just increases the cognitive load.

The thing that confuses me about your reaction is that we’re proposing no new or altered cases in this scheme at all. We’re proposing changing only the value of the version, not any of the semantics of version numbers.

And for users, the proposal ends up removing all of that cognitive load, because it means the only case relevant to day-to-day business is use INTEGER. And if users ever do need to wade into this marsh, they will not have to deal with anything more than is already the case.

We do increase our own cognitive load in the one detail that PERL_REVISION is no longer part of $]/$^V from a certain PERL_VERSION on. This is relevant essentially only for the porters/toolchain crowd and XS authors, and only in such XS code that (thinks it) needs to cross-reference those two sources of truth for some reason. The reason to take on this (IMO minor) increase in cognitive load is that we get to simply decline to pay the transition cost of bumping PERL_REVISION – which is prohibitive and would otherwise prevent us from creating the huge cognitive load benefit for users. So the gain seems easily worth the cost.

Therefore, on the grounds you outline, it seems like I should expect you to love rather than loathe this proposal. If that still isn’t the case, where am I mistaken?

[ap]

@leonerd

What's this number doing here? I get no clue as to what's going on.

But… you personally do know, no? This preference just seems to me like optimizing for people who have never seen Perl code before – particularly in the context of the future we’re hoping for, where use INTEGER is the first thing every Perl novice learns and the first thing every Perl file starts with.

[karenetheridge]

Various Porting/ files also need to be updated:

: $; ack -il 'perl v?5' Porting
Porting/Maintainers.pl
Porting/README.pod
Porting/add-pod-file
Porting/git-deltatool
Porting/how_to_write_a_perldelta.pod
Porting/makemeta
Porting/new-perldelta.pl
Porting/perldelta_template.pod
Porting/pod_lib.pl
Porting/release_announcement_template.txt
Porting/release_managers_guide.pod
Porting/release_schedule.pod
Porting/security_template.pod
Porting/test-dist-modules.pl
Porting/todo.pod

And lots of entries in pod as well! But all very straightforward though.

[Plato]

I'm betting a very similar thing to any other release notes

I didn't mean the release notes, I meant the marketing copy. What's the official announcement going to say to anyone who happens to notice?

[guest20]

@Plato Maybe you can point me at a previous example of some perl "marketing copy"? I can't personally think of anything that fits this description outside of the release notes...

[bbrtj]

Could it be a good occasion to also get a new logo to which we would have full rights?

[oodler577]

Why after this entire discussion is this still in play?

HOW ABOUT WE TABLE TO DISCUSSION OF CHANGING VERSIONS FOR THE NEXT 100 YEARS. It never ends well, always results in extremely hurt feelings, and inevitably pushes more people away. PLEASE PLEASE PLEASE STOP MESSING WITH THE VERSIONS!

https://www.nntp.perl.org/group/perl.perl5.porters/2024/12/msg269322.html

• We went over our findings so far regarding Perl 42. It looks like Perl
  versions will have to continue to be written with three components, so
  we will be stuck with a fixed .0 at the end. It's slightly annoying,
  but we can live with it. We strategized about how to get more
  real-world data about feasibility, and discussed the possibility of
  releasing a perl-41.8 tarball alongside the regularly scheduled
  perl-5.41.8.

perl-41.8 !!!???

Do you have any idea how much confusion and more black eyes this will cause?

[Grinnz]

Do you have any specific concerns to share?

[happy-barney]

On Mon, 25 Nov 2024 at 16:45, Paul Evans ***@***.***> wrote: On the subject of the v-string numbers specifically: I might be in the minority, but I actually *like* the leading v.

... and you are not alone

If you look at the start of a file and you see use v5.36; you probably have some idea that Perl version 5.36 is a thing. And that leading v gives more of a hint here as to what's going on. "version 5.36", yes that sounds like a related thing here.

little bit off-topic, this exact thoughts lead me to idea of using it as "exact" version of Perl's dialect to use. Message ID: ***@***.***>

…

[happy-barney]

With a two part version there is no need for the super confusing v-string binary-packed decimal notation in the first place, and since 42.1 fits into a regular old number we no longer need version.pm to make things comparable via overload jank.

What did you mean? - v42.100 ? (as currently interpreted) - v42.1 ? (as usual in versioning?) Compare with other languages: - which language as capability to say that in code ? - which language supports work with versioning (eg: javascript's module semver) Message ID: ***@***.***>

…

[happy-barney]

On Mon, 25 Nov 2024 at 17:43, Aristotle Pagaltzis ***@***.***> wrote: @leonerd <https://github.com/leonerd> What's this number doing here? I get no clue as to what's going on. But… you personally do know, no? This preference just seems to me like optimizing for people who have never seen Perl code before – particularly in the context of the future we’re hoping for, where use INTEGER is the first thing every Perl novice learns and the first thing every Perl file starts with.

Maybe not: - number of novices looking into CPAN modules tends to zero - proprietary codebases usually use some kind of "use Project::Common::Sense" which enables all necessary features including version

…

— Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHNE3CG6V65YUVZET3S7RD2CNHTLAVCNFSM6AAAAABSASQXPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYGUZDANJVGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[guest20]

@oodler577 neat English Fact™: To "table" an item means two different things depending on the dialect of the reader.

• In British (and "most" Englishes) it means "bring up in discussion".
• In American it means "remove from discussion".

[guest20]

@happy-barney said, non-at-mentioningly:

What did you mean?

• v42.100 ? (as currently interpreted)
• v42.1 ? (as usual in versioning?)

No, neither of these, because these are both v-strings, and the version will now fit neatly into a float, like a number. 42.1, that is fourty two and one tenth. Not the 2-character string of ascii 42 followed by ascii 1 (or acsii 100) as the v-strings you suggested here would produce. It would be a regular float, and one very far away from the precision limits for floats.

You are asking "What about this confusion we have because we needed v-strings to represent 3 part versions? How does your two part version deal with this problem?". The answer is, "It addresses it directly by actually removing the problem". v-strings will only be useful for neat perl golfs and upsetting newbies on IRC. Possibly as a fun prank for binary packing ip addresses too?

[Grinnz]

On Mon, Dec 23, 2024 at 5:44 AM guest20 ***@***.***> wrote: @happy-barney <https://github.com/happy-barney> said, non-at-mentioningly: What did you mean? - v42.100 ? (as currently interpreted) - v42.1 ? (as usual in versioning?) No, neither of these, because these are both v-strings, and the version will now fit neatly into a float, like a number. 42.1, that is fourty two and one tenth. Not the 2-character string of ascii 42 followed by ascii 1 (or acsii 100) as the v-strings you suggested here would produce. It would be a regular float, and one very far away from the precision limits for floats.

How would this work for the version after 42.9? There is a reason versions are not floats in any other software project.

…

-Dan

[guest20]

@Grinnz The exact thing that's already in place when we put version numbers into floats. A leading zero: as seen in use 5.020.

There is a reason versions are not floats in any other software project.

Is it because people want major, minor and point? I bet it's because people want major, minor and point.

[Grinnz]

@Grinnz The exact thing that's already in place when we put version numbers into floats. A leading zero: as seen in use 5.020.

Then it would be 42.001, not 42.1... hence my question.

[guest20]

@Grinnz I guess that was the actual question @happy-barney was asking in the first place too. Thanks for the nudge.

I didn't even consider that this might have been the question because numbers just can't work like that.

So yes, absolutely, 42.1 isn't less than 42.100, for floats to represent versions you gotta zero pad 'em

[happy-barney]

@guest20 yes, that was my question ... and again I don't understand what I did wrong that you had to guess :-(

[guest20]

@happy-barney Since @Grinnz managed to interpret your question correctly and it's very clear what you're asking now I re-read it I can only conclude that the problem wasn't what you wrote, but with what I read. Maybe I got thrown by your use of v-strings in english text, but either way, that's a skill issue on my part.

I guess my tone must have come off pretty shitty to get a :-( from someone with "happy" in their handle/avatar, so sorry for that too.

[happy-barney]

@guest20 I do observe quite frequently that my text is not understand as I meant it (trying to find pattern in it and improve), that :-( was for me

As non-native speaker I do not recognize much of tones in English text (or maybe my brain is wired different ... still same result).

[oodler577]

Given that the tone of this open thread was largely net-negative regarding adding confusion to Perl versioning (which this move does), it appears to be a break in the ranks that I hope will be addressed as an internal matter. My only recourse is to appeal to Perl influencers who are against this but may be withholding their opinions. Releasing a "perl-41.8" would be a significant mistake, and if I can't appeal to the right people to prevent it, then I hope the resulting fallout is severe enough that those responsible face irreparable damage to their reputations and quietly step away.

[book]

Why after this entire discussion is this still in play?

And why reply to a closed PR? I believe the discussion you want to have would be more visible if you opened a new issue on the repository, of you replied directly to the mailing-list post you're quoting.

https://www.nntp.perl.org/group/perl.perl5.porters/2024/12/msg269322.html

perl-41.8 !!!???

Anyone can push a tarball named perl-$version to CPAN (there was a small security scare a few month ago when someone did exactly that). We intend to make sure this won't be indexed as an official perl release.

There will be a regular perl-5.41.8 tarball, released as usual. The point of making a perl-41.8 is to experiment. We intend to go as far as possible with the experiment, to get the best possible understanding of what the technical issues with it are.

[guest20]

Nah, replying to this thread it goes to anybody who's commented here, a new issue only goes to the owners of the repo on github

[book]

So maybe don't cross the streams and reply to the list?