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

Announcing Perl 7

Thread Next
From:
Sawyer X
Date:
June 24, 2020 20:49
Subject:
Announcing Perl 7
Message ID:
CAMvkq_TUsJygOYYT2npu7CYKQLg9F7-5P2YxKfx40UTzSWpAEA@mail.gmail.com
Hi everyone,

A little while ago, I gave a talk[1] at The Perl Conference in the
Cloud where I covered the Plan for Perl that includes the following
significant changes:

* We will begin using major versions again, starting with version 7.
* Major versions will be used for two purposes: 1. Turn on features
and pragmas by default, 2. Remove syntax from the language.
* Features will be guarded within a major version (that is, one *must*
enable new features in 7.x with "use feature") but will be turned on
in the next major version.
* Perl 7.0.0 will be the first release. It will effectively be 5.32.0
with a small number of pragmas (at the very least, strict and
warnings) and features. The goal is to make it as trivial as possible
to upgrade from 5.32.0 to 7.0.0.
* Perl 5 will enter a long-term support window - 5+ years. Exact
number not determined yet.
* We intend to release 7.0.0 within a year. However, I am setting the
goal of releasing it before the end of this year. I want to pave the
way for 7.1.0, which will have the stable release of 7.2.0.
* We will introduce utilities to help upgrade code to Perl 7. For
example, if we were to add signatures by default in 7.0.0 (only *for
example*), we will need code that helps users rewrite "sub foo ($)" as
"sub foo :prototype($)".
* We will also introduce a "compat::perl5" module, which will turn
back the defaults of pragmas and features on 5.32.0. With this change,
one could upgrade to Perl 7 binary immediately without changing the
code. It allows a longer upgrade path.
* We will also introduce a module to help fix up other modules. Such a
module will especially help toolchain and infrastructure for CPAN
manage the automatic upgrade or downgrade of modules without the user
having to fix the code they are installing if it's incompatible.

It would be hard to repeat everything in the talk, so I recommend
watching the talk. The short and sweet is: We need to prioritize users
who *write* Perl versus users who explicitly refuse or cannot update
their code. In our current prioritization, we force all existing users
and new users to manage the technical debt of previous generations.

There is *a lot* to figure out at this point. We need to:
* Update the internal code to support "use strict" and "use warnings".
* Bump to 7.0.0.
* Determine which pragmas and features will be enabled and turned on.
* Determine how long we will support Perl version 5.
* Determine the criteria for bumping major versions. Time might not be
the best metric.
* Create tickets for issues to be done so that the community could
help. (People have already reached out, wanting to support this
effort.)
* Make sure we clarify what gets backported to Perl 5.32.x. Right now,
it's the same criteria as every other maint release, except for a much
longer time-frame.
* Work on moving to 7.0.0 is already underway on the p7 branch here:
https://github.com/atoomic/perl

Additional comments:
* Yearly releases for minor versions will continue as planned.
* Monthly releases for dev versions will continue as planned.
* See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.
7.2.0 will be akin to 5.34.0.
* As exciting as 7.0.0 will be, it will mostly be there just to put us
on our path. 8.0.0 will likely be much exciting.
* There are notable stakeholders to the language which will be working
with us to update their code to 7.0.0 defaults, to help understand the
possible consequences.
* We will need to rename the GitHub repo. That's okay because GitHub
creates an automatic redirect for the URLs, including the GitHub clone
paths.
* /usr/bin/perl is owned by distributions. We are not in charge of it.
We will be providing support to vendors and distributions and help
them reach good decisions and move forward in the manner they choose.

I apologize for not sharing this news earlier. We have been working on
this plan for a very long time. p5p is a public mailing list, and we
needed to manage the communication around this. Despite not being
public, many people worked on it. Vital core developers, numerous core
contributors, several significant stakeholders, vendors/distributions,
and people with an in-depth history in Perl and the core code - were
all involved. We have done a *lot* of work to get to where we are.
While it's not a fully detailed change proposal, we have gone through
quite a lot and tried to be very thorough while leaving room for
things to now be openly discussed.

Several threads will likely begin on the list to address specific
issues listed above. I imagine this thread will itself receive a lot
of responses and soon become sprawling. To manage this, I will open
several threads, over several weeks, so we could have "waves" of
discussions, instead of one monster thread in which we might quickly
lose both our place and our focus. When discussing these topics, I
request people to communicate mindfully and constructively.

I want to thank everyone who helped work on this plan and shape it
into what it is today. These are too many people to mention, but I
want you to know I appreciate the effort, the time, the thorough
reviews, the feedback, the ideas, and the solutions.

Sawyer.

[1] https://www.youtube.com/watch?v=6wPMh-3qYJM

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About