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

Re: Perl moving above 5.x version numbers

Thread Previous | Thread Next
Darren Duncan
May 19, 2020 19:41
Re: Perl moving above 5.x version numbers
Message ID:
Yes, what Dan said, is my motivation, its about perception that Perl is moving 
forward regularly.

Also, just shifting the numbers, whether its done for 34 or 36 or whenever we're 
ready, shows respect to Perl's long history and many updates over the years, it 
more properly represents how much has been built over the years.

Incrementing the first version per yearly release is helping Postgres' 
perception, and other projects, which have moved to doing that.

I'm not specifically proposing that this needs to be rushed for next year.

Other than the work involved to make sure the tooling and ecosystem works with 
the updated scheme, which can take as much time as it needs to, is there really 
any strong tie to calling Perl version 5 forever that people say they'd rather 
not change?

-- Darren Duncan

On 2020-05-19 9:02 a.m., 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.
> 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