develooper Front page | perl.perl5.porters | Postings from June 2021

Re: PSC #025 2021-06-18 minutes

Thread Previous
mah.kitteh via perl5-porters
June 28, 2021 04:38
Re: PSC #025 2021-06-18 minutes
Message ID:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, June 27th, 2021 at 12:08 PM, Dan Book <> wrote:

> On Sun, Jun 27, 2021 at 5:55 AM Nicholas Clark <> 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.
> is dual life, and often a recommended way to use experimental features. Perhaps this can be leveraged as such a mechanism?
> -Dan

FWIW, I was watching this year-old video on ZFS, and Allan Jude covers some aspect of how the OpenZFS project is managed (from the perspective of FreeBSD).

In particularly, the concept of "feature flags" seems somewhat applicable to perl. I am not saying it's directly applicable, the challenges are different. However, this model is similar enough that it might provide some further refinements to how perl handles features, experiements, etc.

Some background on ZFS feature flags:


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About