develooper Front page | perl.perl5.porters | Postings from May 2020

Re: Perl moving above 5.x version numbers

Thread Previous | Thread Next
Dan Book
May 19, 2020 16:02
Re: Perl moving above 5.x version numbers
Message ID:
On Tue, May 19, 2020 at 1:39 AM Darren Duncan <>

> Now that Raku has, or is in the process of, no longer using the Perl
> version
> namespace, has there been any serious consideration by the Perl 5 Porters
> to
> start exploiting version numbers above 5.x for major releases?
> I propose, if possible, that the next major production version of Perl
> after
> 5.32 be 34.0, and then continue on in that manner afterwards.
> As for dealing with distinguishing development versus production, the
> smallest
> change would be just to take the current process and shift it to the left,
> so eg
> 33.x is dev (or as a special case could be 5.33.x as a transitional
> exception),
> 34.x is prod, 35.x is dev, and so on.
> Do we consider that Perl is free to independently make this move, or does
> anyone
> feel that Raku still has to do more than they have done first so that
> conflicts
> or incompatibilities can be prevented?

I think this is worth considering from an appearances standpoint.

Let me say right out, that using 6 or 7 is out of the question. They would
both only add to confusion and contention between communities. The Raku
community has done a lot of work and gone through a lot of pain (and still
are) to stop appearing to clobber Perl's namespace. A new version of Perl 6
or 7 would just reassert these issues of identity between the two
languages, and add confusion to the numerous resources that will be
referencing "Perl 6" for years to come.

Higher numbers are worth exploring. Consider that to the outsider, Perl 5.8
and Perl 5.30 seem like a small difference in version. I experience this
every time a new user says they have some ancient version of Perl and don't
realize that 5.30 is a decade newer. This lends itself to the appearance
that Perl is not continuously developed and does not have major releases
every year. We know this is not true, but if we want to make it clearer to
the public, our versioning scheme needs to better represent this reality.

There is the argument that considering every major release a "major
version" is too much, that Perl doesn't change that much. I would argue
that we already call them major version releases, and they are already ABI
incompatible, they already effectively are major version releases that most
would expect, in everything but having drastically incompatible user-facing
changes. But Perl is never going to do that, it's not what we are about. So
there's something to be said for matching the appearance to the reality
such as it is.

Why jump to the second version number component as the major version? Sure
it feels Java-esque. But it's already what many things treat as the major
version, and it causes no appearance of relation to
previously-known-as-Perl-6. It's not ideal, but it's an option. I don't
think we should impose any deadline of doing this by 5.34 or 5.36 or
whatever, just as examples. The logistics may seem simple but there is a
lot of ecosystem out there to untangle.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About