Front page | perl.perl5.porters |
Postings from August 2020
On Thu, 2020-08-06 at 01:12 +0200, Tomasz Konojacki wrote: > On Wed, 5 Aug 2020 16:46:31 -0400 > Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: > > There are a lot of specific changes being discussed. Everyone on the PSC seems > > to agree on Perl 7.0.0 existing at some point in the next twelve months. > > Beyond that, it's up in the air. > > There's no reason why we have to release Perl 7 *now*, other than saving > Sawyer's face and brian's book sales. BTW, AFAIK it's not true that > there's a full consensus among PSC members about this. > > In my opinion, the only way forward is to release Perl 5.36 which will > add deprecation warnings for the stuff we want to remove/disable by > default in Perl 7 and then continue making 5.x releases until we are > actually ready to release Perl 7. That will, of course, take a few years. > > Releasing Perl 7 in the way that was described in Sawyer's talk will > result in a catastrophe. It will be a PR disaster (it already is), it > will fragment the community and possibly even result in a hard fork of > Perl (BTW, as someone who has contributed 32 commits to Perl in the past > year, I will probably support it, if it happens). Why would a hard fork of Perl 5 be preferable to Perl 5 and Perl 7 being maintained under the same umbrella by the same people? Sawyer's talk stated that Perl 5 will be maintained without any breaking changes for users that don't want new features or don't feel ready to upgrade. Perl 5 will be more stable than it currently is, not less. What would a fork of Perl 5 aim to accomplish that isn't already part of the plan to maintain Perl 5 while Perl 7 moves forward? I'm not trying to be facetious... I see the Perl 5 long term support aspect of the plan as a significant improvement to the status quo. It should make changes to core Perl less of a risk for anyone tending legacy codebases. J.D.Thread Previous | Thread Next