Mailing List Archive

Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features
Today github broke a large amount of the internet's github centric
build chains by upgrading git. (See "Stability of git-archive,
breaking (?) the Github universe, and a possible solution" (message id
<a812a664-67ea-c0ba-599f-cb79e2d96694@gmail.com> on the git list)

In the ensuing discussion there were repeated mentions of "Hyrums
law"[1]. I hadnt heard the term so I went to read up on it at

https://www.hyrumslaw.com/

It turns out this law can be summed up as:

"With a sufficient number of users of an API, it does not matter what
you promise in the contract: all observable behaviors of your system
will be depended on by somebody."

This is pretty much the same conversation about PERL_USE_VOLATILE_API
that we are having in https://github.com/Perl/perl5/pull/20744 and the
same problem we have had with warnings categories, with experimental
features, etc.

One of the corroloraries of this law is that if an API is sufficiently
stable, no matter how it is marked or documented, it will be treated
as stable regardless.

The only way to prevent this from happening is to make the API
actually unstable. For instance, I have seen Perl classes choose
randomly from one of three different internal representations (hash,
array, and scalar reference based objects) at random at startup to
prevent users from exploiting "unwarranted chumminess" with the
internals of the objects it produces. Anyone dumb enough to pierce the
veil of the object would find their next run failed with a fatal
error.

I have been thinking that maybe we should do something similar for
PERL_USE_VOLATILE_API, and maybe also with experimental apis. For
instance we could specify a PERL_USE_VOLATILE_API key for each
(major?) release. Anything using the API's would have to specify the
correct key in the define for each version of perl. This would ensure
that people understand that if they are to use the volatile API they
will have to update their code *each* *release*. Similarly we could do
the same with experimental features. Each release we could specify a
string that must be provided to these features (or maybe set in the
environment or something), so that they continue to work.

This would ensure that people understand that if they use these
volatile or experimental things there will be a permanent maintenance
burden from doing so, and that they will have to deal with breakage
every release.

Of course this would strongly dissuade people from using experimental
features in production, and it would impose a maint burden on XS
authors using these volatile API's but it would free us from having to
deal with the fallout when we actually do change these things and it
causes gnashing of teeth because people have been fooled into thinking
it was stable. After all, if you use something that says on the box
"this will change every release" and it does so consistently then you
can hardly complain when it changes in a more substantial way.

I dunno if this is really a good idea, but I thought we should at
least talk about it a bit. I know some folks will hate it for sure,
but I wonder if it would make maintaining the internals and
experiments easier and maybe drive adoption of experimental features
more quickly. If there is no disadvantage of using an experimental or
volatile API then there is no reason not to use it without feeding
back that the experimental status should be removed. But if you know
it *will* break every release you might give feedback more quickly so
the experimental feature will be converted to "stable" status. For
PERL_USE_VOLATILE_API it would send the message that using something
marked volatile will necessitate a long term investment, and maybe
encourage people to think carefully about what expectations they have
from of the API.

Maybe it's crazy tho. I can argue it both ways.

Thoughts?

cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
Hi there,

On Tue, 31 Jan 2023, demerphq wrote:

> ... strongly dissuade people from using experimental
> features in production ...

Always assuming that they know that's what they're doing. If I pull
in some random module that's in a long dependency chain just because I
did 'apt-get upgrade' you can imagine how pleased I'll be when I find
that everything I was using yesterday broke this morning. At the very
least I'd expect to see some frustrated and perhaps vitriolic comments
on the mailing lists.

> Thoughts?

I've said it before and I make no apology for saying it again:

above all else, people want STABILITY.

The people tinkering with Perl probably number a few dozen.

Directly or indirectly it probably supports and affects a few hundred
million people, and most of them won't even know it. For example see

https://en.wikipedia.org/wiki/Comparison_of_web_hosting_control_panels

STOP EXPERIMENTING on Perl 5. It's not your personal playground, it's
part of the infrastructure. Get rid of *EVERYTHING* that you consider
to be experimental. If you want to tinker, tinker in Perl 7 where you
won't cause any aggravation for the people trying to get things done.

--

73,
Ged.
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
From the keyboard of demerphq [31.01.23,10:14]:

[...]
> I have been thinking that maybe we should do something similar for
> PERL_USE_VOLATILE_API, and maybe also with experimental apis. For
> instance we could specify a PERL_USE_VOLATILE_API key for each
> (major?) release. Anything using the API's would have to specify the
> correct key in the define for each version of perl. This would ensure
> that people understand that if they are to use the volatile API they
> will have to update their code *each* *release*. Similarly we could do
> the same with experimental features. Each release we could specify a
> string that must be provided to these features (or maybe set in the
> environment or something), so that they continue to work.

This would make things worse towards two directions - stable, and
experimental.

> This would ensure that people understand that if they use these
> volatile or experimental things there will be a permanent maintenance
> burden from doing so, and that they will have to deal with breakage
> every release.

People using experimental or volatile things *already know* that
these things are *volatile or experimental*, they would not experiment
any benefit from the procedure, but get more reluctant to try things
due to the burden placed upon them.

> Of course this would strongly dissuade people from using experimental
> features in production, and it would impose a maint burden on XS
> authors using these volatile API's but it would free us from having to
> deal with the fallout when we actually do change these things and it
> causes gnashing of teeth because people have been fooled into thinking
> it was stable. After all, if you use something that says on the box
> "this will change every release" and it does so consistently then you
> can hardly complain when it changes in a more substantial way.

I can't imagine how any reasonable developer would want to use things
experimental or volatile in production, except if it is a crucial change
which allows them to scratch a very old itch.

See, any good Burger King uses well seasoned loafs of meat in their
daily work because they don't want to be hit by the annoyance of a
steak jumping out their frying pan after applying a pinch of salt.
Or pepper, chili, your choice.

> I dunno if this is really a good idea, but I thought we should at
> least talk about it a bit. I know some folks will hate it for sure,
> but I wonder if it would make maintaining the internals and
> experiments easier and maybe drive adoption of experimental features
> more quickly. If there is no disadvantage of using an experimental or
> volatile API then there is no reason not to use it without feeding
> back that the experimental status should be removed. But if you know
> it *will* break every release you might give feedback more quickly so
> the experimental feature will be converted to "stable" status. For
> PERL_USE_VOLATILE_API it would send the message that using something
> marked volatile will necessitate a long term investment, and maybe
> encourage people to think carefully about what expectations they have
> from of the API.

Dunno either. But I would argue that perl engines which milk the cow
(who ist the cow, the milker and the profiteer anyways?) don't change
very much unless the are utterly rotten. The cow chomps the grass, the
perl milks the cow, the tinkerer owns his cash, the profiteer profits.

But adding another "There be dragons!" facility or a "oh noes! another
pile of rhinos!" doesn't help neither the geeks nor the old beards.

> Maybe it's crazy tho. I can argue it both ways.
>
> Thoughts?
>
> cheers,
> Yves
>

0--gg-

--
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
Op 31-01-2023 om 12:23 schreef G.W. Haywood via perl5-porters:
> STOP EXPERIMENTING on Perl 5.  It's not your personal playground, it's
> part of the infrastructure.  Get rid of *EVERYTHING* that you consider
> to be experimental.  If you want to tinker, tinker in Perl 7 where you
> won't cause any aggravation for the people trying to get things done.
>

I read Yves mail as a plea for predictability, and thus stability. I
find the above statement uncalled for, unhelpful and even wrong. Wrong
because perl 7 should provide the same stability as we want for Perl 5,
complete with backward compatibility with Perl 5. Which is exactly what
Yves is addressing. You may disagree with the approach to achieve this
stability, but that does not call for a response like this.


M4
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Tue, 31 Jan 2023 at 19:20, shmem <shmem@cruft.de> wrote:
>
> From the keyboard of demerphq [31.01.23,10:14]:
>
> [...]
> > I have been thinking that maybe we should do something similar for
> > PERL_USE_VOLATILE_API, and maybe also with experimental apis. For
> > instance we could specify a PERL_USE_VOLATILE_API key for each
> > (major?) release. Anything using the API's would have to specify the
> > correct key in the define for each version of perl. This would ensure
> > that people understand that if they are to use the volatile API they
> > will have to update their code *each* *release*. Similarly we could do
> > the same with experimental features. Each release we could specify a
> > string that must be provided to these features (or maybe set in the
> > environment or something), so that they continue to work.
>
> This would make things worse towards two directions - stable, and
> experimental.

Yeah, I'm starting to think that the cure will be worse than the disease.

> > This would ensure that people understand that if they use these
> > volatile or experimental things there will be a permanent maintenance
> > burden from doing so, and that they will have to deal with breakage
> > every release.
>
> People using experimental or volatile things *already know* that
> these things are *volatile or experimental*,

Well, while that is true, we have gotten yelled at for changing
experimental things, and people like Dave M feel handcuffed in
improving parts of the internals by the fact we have exposed some of
them as API's. A perfect example of Hyrums law. I think we have even
gotten yelled at for de-experimentalizing things because then the use
statement that allowed them no longer works. Damned if you do, damned
if you don't.

> they would not experiment
> any benefit from the procedure, but get more reluctant to try things
> due to the burden placed upon them.


> > Of course this would strongly dissuade people from using experimental
> > features in production, and it would impose a maint burden on XS
> > authors using these volatile API's but it would free us from having to
> > deal with the fallout when we actually do change these things and it
> > causes gnashing of teeth because people have been fooled into thinking
> > it was stable. After all, if you use something that says on the box
> > "this will change every release" and it does so consistently then you
> > can hardly complain when it changes in a more substantial way.
>
> I can't imagine how any reasonable developer would want to use things
> experimental or volatile in production, except if it is a crucial change
> which allows them to scratch a very old itch.

We see signs of it all the time tho.

> See, any good Burger King uses well seasoned loafs of meat in their
> daily work because they don't want to be hit by the annoyance of a
> steak jumping out their frying pan after applying a pinch of salt.
> Or pepper, chili, your choice.

Not sure I get the analogy here. TBH, but your vote against the idea
is registered. :-)

Cheers,
yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Tue, 31 Jan 2023 at 22:09, Martijn Lievaart <m@rtij.nl> wrote:
>
> Op 31-01-2023 om 12:23 schreef G.W. Haywood via perl5-porters:
> > STOP EXPERIMENTING on Perl 5. It's not your personal playground, it's
> > part of the infrastructure. Get rid of *EVERYTHING* that you consider
> > to be experimental. If you want to tinker, tinker in Perl 7 where you
> > won't cause any aggravation for the people trying to get things done.
> >
>
> I read Yves mail as a plea for predictability, and thus stability. I
> find the above statement uncalled for, unhelpful and even wrong. Wrong
> because perl 7 should provide the same stability as we want for Perl 5,
> complete with backward compatibility with Perl 5. Which is exactly what
> Yves is addressing. You may disagree with the approach to achieve this
> stability, but that does not call for a response like this.

Thanks. All I am trying to do is figure out a way that we can continue
to make perl better, faster, etc, without getting into the trap where
older inefficient internals cannot be replaced because someone has
made a hard dependency on them and then yells at us when we break
them. I think making everybodies perl faster and better is more
important than ensuring that every existing piece of software can
continue to run unchanged on a new perl. Anyone who wants complete
stability has an easy way to achieve it: do not upgrade, ever.

Anyway, I guess this idea was crazy. I just want to figure out a way
that Dave and others can work on optimizing and fixing the internals
without being accused of crimes akin to eating peoples babies by
breaking back compat guarantees that we never really made.

Cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Tue, 31 Jan 2023 10:14:12 +0100
demerphq <demerphq@gmail.com> wrote:

> Thoughts?

Having been on both sides of this - both as a frequent user of Perl's
crazier internals as part of quite a few CPAN modules, and a creator /
implementor of bits of those same internals, I think there's a
compromise position to be found in the middle.


I think we're right to pick a different word than "experimental" here.
"experimental" tends to mean something quite different to what we're
doing with some of the API things. I think "VOLATILE_API" is a much
better marker.

With "experimental" features exposed at the language level, we say we
might accept them as-is (as often happens), adjust them somewhat over
time (e.g. signatures), or remove them entirely (e.g. smartmatch). But
this is all done over an evaluation of what the feature is and how
people are using it. It's an experiment to see "does this work?".

The lifetime I can imagine for VOLATILE_API is a different shape. With
the current optimize_optree+finalize_optree being marked as that, I
think the statement we should be making is something like:

These API functions are tied to our particular implementation of this
part of the internals. We might change or remove them at any time,
but we expose them as API because we accept that you might be wanting
to use them for (this kind of task). Accepting that, if we do change
or remove them so they are no longer available for this task, we aim
to provide something else instead.

I.e. the volatile API is only provided because it's necessary for some
other module or piece of code to actually work. It's there purely as a
service to support some other thing, rather than a headline feature in
its own right. There's no experiment to be performed, beyond observing
"Yes, this makes that thing work".

Again with the specifics of this case in mind, this feels like the sort
of thing that as a module author (my List::Keywords uses these APIs)
I'd want to know. I don't care if this exact API disappears in a future
version of perl; what I care about is whether I can still have
*something* that does the same thing, that I can provide to the users
of List::Keywords. Those users don't care about how List::Keywords does
its thing, they just want to know that it is done, somehow.


This brings me on to my second thought, which is one of transitivity.
Currently there's nothing that anyone even suggests, to say that
modules that use experimental/volatile features should give any sort of
hint of that fact to their own downstream users. Perhaps that's
something we should start to suggest? E.g. in my case maybe somewhere
in the documentation of List::Keywords I should point out that it uses
perl API functions marked as "VOLATILE_API", and so its longterm
ability to continue to work may be dependent on that.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Wed, 1 Feb 2023 at 13:19, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> On Tue, 31 Jan 2023 10:14:12 +0100
> demerphq <demerphq@gmail.com> wrote:
>
> > Thoughts?
>
> Having been on both sides of this - both as a frequent user of Perl's
> crazier internals as part of quite a few CPAN modules, and a creator /
> implementor of bits of those same internals, I think there's a
> compromise position to be found in the middle.
>
>
> I think we're right to pick a different word than "experimental" here.
> "experimental" tends to mean something quite different to what we're
> doing with some of the API things. I think "VOLATILE_API" is a much
> better marker.
>
> With "experimental" features exposed at the language level, we say we
> might accept them as-is (as often happens), adjust them somewhat over
> time (e.g. signatures), or remove them entirely (e.g. smartmatch). But
> this is all done over an evaluation of what the feature is and how
> people are using it. It's an experiment to see "does this work?".
>
> The lifetime I can imagine for VOLATILE_API is a different shape. With
> the current optimize_optree+finalize_optree being marked as that, I
> think the statement we should be making is something like:
>
> These API functions are tied to our particular implementation of this
> part of the internals. We might change or remove them at any time,
> but we expose them as API because we accept that you might be wanting
> to use them for (this kind of task). Accepting that, if we do change
> or remove them so they are no longer available for this task, we aim
> to provide something else instead.
>
> I.e. the volatile API is only provided because it's necessary for some
> other module or piece of code to actually work. It's there purely as a
> service to support some other thing, rather than a headline feature in
> its own right. There's no experiment to be performed, beyond observing
> "Yes, this makes that thing work".
>
> Again with the specifics of this case in mind, this feels like the sort
> of thing that as a module author (my List::Keywords uses these APIs)
> I'd want to know. I don't care if this exact API disappears in a future
> version of perl; what I care about is whether I can still have
> *something* that does the same thing, that I can provide to the users
> of List::Keywords. Those users don't care about how List::Keywords does
> its thing, they just want to know that it is done, somehow.

I very much like the way you are approaching this. I think you make a
good point about the difference in experiemental features at the perl
level, and volatile apis at the XS/internals level. I think your
proposed verbiage above should be in the docs.

>
> This brings me on to my second thought, which is one of transitivity.
> Currently there's nothing that anyone even suggests, to say that
> modules that use experimental/volatile features should give any sort of
> hint of that fact to their own downstream users. Perhaps that's
> something we should start to suggest? E.g. in my case maybe somewhere
> in the documentation of List::Keywords I should point out that it uses
> perl API functions marked as "VOLATILE_API", and so its longterm
> ability to continue to work may be dependent on that.

This is a very good point. The toolchain could be taught about this so
that people werent surprised to discover they are using experimental
features in production without their knowledge.

++ on this post. Very thoughtful.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Tue, Jan 31, 2023 at 9:28 PM demerphq <demerphq@gmail.com> wrote:

> I think we have even
> gotten yelled at for de-experimentalizing things because then the use
> statement that allowed them no longer works. Damned if you do, damned
> if you don't.
>

For the record, "use experimental X" should continue working fine after a
feature has been de-experimentalized, and I believe "no warnings
'experimental::X'" has similar protections.

-Dan
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Wed, Feb 01, 2023 at 12:19:04PM +0000, Paul "LeoNerd" Evans wrote:
> The lifetime I can imagine for VOLATILE_API is a different shape. With
> the current optimize_optree+finalize_optree being marked as that, I
> think the statement we should be making is something like:
>
> These API functions are tied to our particular implementation of this
> part of the internals. We might change or remove them at any time,
> but we expose them as API because we accept that you might be wanting
> to use them for (this kind of task). Accepting that, if we do change
> or remove them so they are no longer available for this task, we aim
> to provide something else instead.

But the practical problem remains. You (as in Paul) use a VOLATILE API in
your XS code, with the good intention of always being prepared to modify
your XS code if someone like me changes the volatile function. Then five
or ten years later, you are (for whatever reason) no longer active in the
perl community; I change that volatile function, and a bunch of CPAN
modules suddenly break. Whose responsibility is it to fix the XS code? If
those modules are widely used, will it then be agreed that my changes must
be backed out if I'm not prepared to fix up the XS code?

In XS API land, we currently have two main states:

1) marked as API: we try very hard not to break the API, try to add tests
to XS::APItest etc. Sometimes something in the API implementation
deliberately or inadvertently changes, and there's lots of discussion and
angsting, often with the change being reverted during development; or if
it breaks only a few distros, we go and fix those distros too.

2) not marked as API. We change those functions without much thought. We
then get BBC reports because someone was using a non-API function. We then
go through the same angsting process as (1) about whether to revert or
supply patches to CPAN authors etc.

At the moment its not clear to me how a VOLATILE_API flag will solve the
problems of (1) and (2).

--
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Tue, Jan 31, 2023 at 11:23:14AM +0000, G.W. Haywood via perl5-porters wrote:
> STOP EXPERIMENTING on Perl 5. It's not your personal playground, it's
> part of the infrastructure. Get rid of *EVERYTHING* that you consider
> to be experimental. If you want to tinker, tinker in Perl 7 where you
> won't cause any aggravation for the people trying to get things done.

So are you of the opinion that perl should have had no new features added
to it since the 5.000 release in 1994?

--
Lear: Dost thou call me fool, boy?
Fool: All thy other titles thou hast given away; that thou wast born with.
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Sat, 4 Feb 2023 at 13:03, Dave Mitchell <davem@iabyn.com> wrote:
>
> On Wed, Feb 01, 2023 at 12:19:04PM +0000, Paul "LeoNerd" Evans wrote:
> > The lifetime I can imagine for VOLATILE_API is a different shape. With
> > the current optimize_optree+finalize_optree being marked as that, I
> > think the statement we should be making is something like:
> >
> > These API functions are tied to our particular implementation of this
> > part of the internals. We might change or remove them at any time,
> > but we expose them as API because we accept that you might be wanting
> > to use them for (this kind of task). Accepting that, if we do change
> > or remove them so they are no longer available for this task, we aim
> > to provide something else instead.
>
> But the practical problem remains. You (as in Paul) use a VOLATILE API in
> your XS code, with the good intention of always being prepared to modify
> your XS code if someone like me changes the volatile function. Then five
> or ten years later, you are (for whatever reason) no longer active in the
> perl community; I change that volatile function, and a bunch of CPAN
> modules suddenly break. Whose responsibility is it to fix the XS code? If
> those modules are widely used, will it then be agreed that my changes must
> be backed out if I'm not prepared to fix up the XS code?
>
> In XS API land, we currently have two main states:
>
> 1) marked as API: we try very hard not to break the API, try to add tests
> to XS::APItest etc. Sometimes something in the API implementation
> deliberately or inadvertently changes, and there's lots of discussion and
> angsting, often with the change being reverted during development; or if
> it breaks only a few distros, we go and fix those distros too.
>
> 2) not marked as API. We change those functions without much thought. We
> then get BBC reports because someone was using a non-API function. We then
> go through the same angsting process as (1) about whether to revert or
> supply patches to CPAN authors etc.
>
> At the moment its not clear to me how a VOLATILE_API flag will solve the
> problems of (1) and (2).

I dont think it solves those problems alone. I do think it goes some
way to simplify the debate about whether they should have been using
it, and what the implications were.

I think it is an improvement to make the volatile nature of these apis
clear, even if it doesn't totally solve the general problem. I
certainly think it's better than blessing some of these subs as API
grade where we have a clear commitment to maintain the API.

I dont know that there is a real solution to these problems, but I do
think that explicitly flagging them in the way that VOLATILE_API does
is a tiny step forward. At the very least it will avoid a certain
part of the discussion and debate and maybe remove some of the angst
from case 2.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
On Sat, Feb 4, 2023 at 11:06 PM Dave Mitchell <davem@iabyn.com> wrote:

> [snip]
>
> So are you of the opinion that perl should have had no new features added
> to it since the 5.000 release in 1994?
>
>
I could be mistaken, but I felt that G.W.Haywood was instead expressing the
opinion that perl 5 should have had no new features added to it since the
5.000 release in 1994 ... the idea being that "new features" would be
delayed until the next major release (which, in 1994, would have been
deemed to be "6", but has now morphed into "7").
Isn't that one of the things that "next major releases" are for ?

I shouldn't be presuming to speak on his behalf, but his POV resonated with
me.

Cheers,
Rob
Re: Applying Hyrums law to PERL_USE_VOLATILE_API and experimental features [ In reply to ]
sisyphus wrote:
>
> ... the idea being that "new features" would be delayed until the next major release (which, in 1994, would have been deemed to be "6", but has now morphed into "7").
> Isn't that one of the things that "next major releases" are for ?


While the notion that Perl 7 would be the next major release was indeed circulated a few years ago, the current position of the PSC seems to be that Perl 5 and Perl 7 are effectively the same major release.

The switch to version number 7 is intended to be mostly marketing, I think. In the words of the PSC: "[It] tells people to come look, because they might realize they'd like to start doing some more work in Perl." In that sense, the number of new features that Perl version 7.0 in particular brings might very well end up being zero, all new features already having been added in earlier 5.x releases.

https://blogs.perl.org/users/psc/2022/05/what-happened-to-perl-7.html

https://www.nntp.perl.org/group/perl.perl5.porters/2022/05/msg263767.html


--
Arne Johannessen
<https://arne.johannessen.de/>