Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Tom Molesworth via perl5-porters
Date:
June 30, 2020 05:41
Subject:
Re: Announcing Perl 7
Message ID:
CAGXhHdmi8yYAzxO70Sf_KH_brvDh38gsB_dS0=P1MucgFfV=bw@mail.gmail.com
On Tue, 30 Jun 2020 at 13:33, Darren Duncan <darren@darrenduncan.net> 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...
Thread Previous
|
Thread Next