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

Re: Perl moving above 5.x version numbers

Thread Previous | Thread Next
Joseph Brenner
May 19, 2020 19:31
Re: Perl moving above 5.x version numbers
Message ID:
(1) continue using current versioning for internal purposes

(2) for external, announcement/marketing purposes, start using the
year and month.

On 5/19/20, Dan Book <> wrote:
> On Tue, May 19, 2020 at 1:39 AM Darren Duncan <>
> wrote:
>> 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.
> -Dan
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to

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