Front page | perl.perl5.porters |
Postings from July 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Dan Book
Date:
July 2, 2020 15:56
Subject:
Re: Announcing Perl 7
Message ID:
CABMkAVWi5J8zuFZjCUBnHLTEp5fZFAYPxnE7SQLMNhdSWopvYw@mail.gmail.com
FYI, I have collected my core thoughts on the discussion here:
http://blogs.perl.org/users/grinnz/2020/07/perl-7-a-risk-benefit-analysis.html
-Dan
On Wed, Jun 24, 2020 at 4:49 PM Sawyer X <xsawyerx@gmail.com> wrote:
> 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 Previous
|
Thread Next