Front page | perl.perl5.porters |
Postings from August 2020
Re: Q: what the hell is going on? // A: ...
From: Craig A. Berry
August 7, 2020 23:01
Re: Q: what the hell is going on? // A: ...
Message ID: CA+vYcVwFHhovj6G3mVnqkcr4=LgoHPph03fnGf--2SqHyVC1MQ@mail.gmail.com
On Thu, Aug 6, 2020 at 4:38 PM John Lightsey <firstname.lastname@example.org> wrote:
> On Thu, 2020-08-06 at 11:39 -0500, Craig A. Berry wrote:
> > Changing what features are enabled by default in no way requires one
> > big bet-the-farm incompatible change on short notice. Consider an
> > alternate universe in which v5.32 was released along with an
> > announcement that in v5.36, "use v5.12" or equivalent would be on by
> > default and in v5.40 would become mandatory. Paul Evans has recently
> > reminded us of just how much that does. People would have five
> > years to get ready for the end of support of 5.38.x, including getting
> > CPAN and the toolchain into a form where a module version can specify
> > the minimum and maximum Perl versions it supports. Meanwhile, v5.34
> > could announce a new feature bundle to be enabled in v5.38 and
> > mandatory in v5.42. Lather, rinse, repeat. And possibly rename 5.40.0
> > to 7.0.0 and use a new major version whenever a new feature bundle
> > becomes mandatory.
> I don't understand why supporting a stable Perl 5 and releasing a
> slightly more fast-moving Perl 7 are mutually exclusive.
> I would assume Perl 5 going into a maintenance mode long term support
> phase give users the option of adopting Perl 7 on their own timeframe
> when they are ready to do so. I would also assume that users sticking
> with Perl 5 don't want disruptive changes in Perl 5.
> You're saying they'll have no notice with the current plan...and that
> switching the behaviors in a minor version release will be less of a
> hassle to users than doing so across a major version release.
> The approach you favor is definitely more consistent with the current
> Perl 5 release practices. Whether the current release practices are
> helping the long term outlook for the Perl language seems debatable.
> To me, the reasonably broad support for doing something different
> (ignoring disagreements over what form that "something" should take)
> suggests that there are a lot of people who feel like the long term
> future of the Perl language is in doubt.
> If you don't agree with that sentiment, then indeed the status quo is
> working very well and there's no good reason to change it.
> If you do agree with that sentiment, then is a five year transition plan
> to Perl 7 honestly going to improve things?
The major lesson of the 5.10 era was that a steady rhythm of
predictable, modest, scheduled changes works much better than big
singleton changes of unknown scope, with an unknown impact, and on an
unknown schedule. Jesse dragged us out of that and things have gone
much more smoothly since.
The Perl 7 announcement partially addresses scope, impact, and
schedule (or at least acknowledges that these things need to be
addressed) but it is still what I am calling a singleton change, i.e.,
a one-of-a-kind event that resets the game board and ushers in a new
way of doing things. Except the announcement also mentions Perl 8,
which will presumably usher in another, incompatible, way of doing
things. If I change all my code to work under Perl 7, will I have to
change it all again when Perl 8 comes out? What will I have to
change, and when will I have to change it? The rules for how things
change are clearly changing, but what exactly are the new rules?
If it really is desirable or necessary to give up on backward
compatibility in order to move the language forward, then it seems to
me the only sane way forward is to stop thinking of backward
compatibility as a yes or no question and start thinking of it as a
"how much?" question. In my opinion, that question should have been
settled before anything else, but better late than never.
There is not a single original thought in this e-mail. It's simply
what every other mature project that does not preserve backward
compatibility indefinitely does. Java 9 broke a lot of things, but
Java 8 is still supported and people have had years of notice in both
documentation and compiler warnings about what needs to be changed and
when. Even Angular, which rewrote everything from scratch for 2.0,
breaking every single user's code in the process, has clued in to the
fact that communicating what will change and when is important. Their
pace is insane: they have a new major release every 6 months and only
guarantee backward compatibility for 18 months, but *at least they
tell you* what you will need to change and when.