Front page | perl.perl5.porters |
Postings from June 2021
Re: PSC #025 2021-06-18 minutes
Thread Previous
|
Thread Next
From:
Dan Book
Date:
June 27, 2021 17:09
Subject:
Re: PSC #025 2021-06-18 minutes
Message ID:
CABMkAVXPW01ck6sfRBium_4w2G_VX1g3zqR8hh3BC-No2sawqQ@mail.gmail.com
On Sun, Jun 27, 2021 at 5:55 AM Nicholas Clark <nick@ccl4.org> wrote:
> ## Minimum perl versions (and encouraging adoption of our new features)
>
> We discussed how it's frustrating that each year we ship a new version of
> Perl, but the take up of the improvements is limited because folks shipping
> code to CPAN are reluctant to use them because they favour supporting the
> long tail of older versions. At some level, this conflict of incentives
> actually makes it arguably pointless to try to add features/fix the
> deficiencies of the language, which isn't what we want.
>
> The rough conclusion was that the trade offs that the toolchain authors
> choose is sensible for the toolchain, but we don't think that other modules
> should adopt the toolchain end conclusion *unthinkingly*.
>
I'm not really sure what PSC can do about this, other than make
recommendations. CPAN authors will choose the minimum that they feel is
worth supporting and users will require the minimum they need.
> ## Footnote - "retroactively disable experimental warnings"
>
> When discussing the stability of experimental features, Rik has often noted
> that the first perl version that offered lexical subroutines had an
> implementation with serious bugs, such that you shouldn't use it. But a
> later release (v5.22.0) fixed these, and as nothing changed for two
> releases, it's no longer considered as experimental, and doesn't warn. But
> with hindsight we can say you *can* safely use lexical subs in v5.22.0 or
> later, despite the warning, because we now know that it's good. (The
> warning
> went away in v5.26.0.)
>
> Hence at times we've wondered whether we could implement some way to
> formalise this - split out some part of the implementation of the warnings
> pragma, such that
>
> your code to ask to disable warnings for proven successful experiments we
> could upload updates about "success" to CPAN as a dual life module
>
> That way, we'd get a two year "head start" on the widespread use of new
> features. At the point when experiments end, you could count on at least
> some distributions having already shipped a perl "new" enough to use them
> safely.
>
> We'd not minuted this previously because we didn't have a firmer plan, or
> any need to reference what is a thought experiment. We do now.
>
experimental.pm is dual life, and often a recommended way to use
experimental features. Perhaps this can be leveraged as such a mechanism?
-Dan
Thread Previous
|
Thread Next