Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
From: Darren Duncan
June 30, 2020 06:00
Re: Announcing Perl 7
Message ID: firstname.lastname@example.org
On 2020-06-29 10:40 p.m., Tom Molesworth wrote:
> On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:
> On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:
> > So one concern that does not seem to have been addressed by the "enable by
> > default" proposal is "what about CPAN". It used to be a selling point for
> > would be a shame to lose that.
> Well I DID say that CPAN is one of those places where explicit versions SHOULD
> be used. And if any don't, well CPAN is public, and as you demonstrated we can
> see what would break. And so we now are in the position to fix those modules.
> Fix... how? They aren't broken until we change the rules, some of them haven't
> had a release in years, and are you suggesting that p5p takes responsibility for
> unilaterally releasing patched versions? Ignoring licenses and any other
> concerns, seems like a lot of work - and that hasn't even happened in the past
> for dual-life modules, look at the cases where *core Perl* releases with
> "development versions" of important modules because there's a patch that is not
> yet on CPAN. Have a look at the Scalar-List-Utils sorting discussion from not
> too long ago - even when there's a working patch, it's not always trivial to
> ensure that it makes it into a stable release.
> With limited available resources, and a long list of things to be done - many of
> which are the subject of separate threads which haven't even started yet - it
> would seem safer to avoid a big "release all the modules" project. Maybe some
> more advanced patching option is something that the toolchain is already working
Fix means make compatible. And the argument is for the community at large to do
it, not just those who maintain the Perl interpreter.
I recall various comments that the Perl 7 announcement has lit a fire under the
wider Perl community and a lot of people are chomping at the bit to help the
effort. Well providing compatibility updates to modules is a good use of that.
Lots of modules are in public version control and people wanting to help can
submit pull requests for them. This has happened over the years anyway.
A low-hanging fruit is that if anything doesn't work with use strict it is
updated to declare its variables and so on.
Personally I do NOT advocate that signatures or anything likely to change be
turned on by default, but simpler things unlikely to change should be like "say".
-- Darren Duncan