Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Darren Duncan
Date:
June 30, 2020 06:00
Subject:
Re: Announcing Perl 7
Message ID:
7e3c11d6-a112-fe53-e6fa-826cfb158f7e@darrenduncan.net
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
> Perl,
> > 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
> on...
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
Thread Previous
|
Thread Next