Front page | perl.perl5.porters |
Postings from December 2017
On Sat, Dec 30 2017, Rocco Caputo jotted:
>> On Dec 29, 2017, at 17:32, John Alvord <johngrahamalvord@gmail.com> wrote:
>>
>> Seems like an experimental feature that has been allowed to remain for many years becomes a defacto feature... sort of like a British public footpath. So remove the experimental designation and reduce confusion/friction.
>
> Grandfathering in experimental features isn't a design process. It should not be done on the metaphorical eve of having a process.
>
> I propose that the "experimental" flag be deprecated.
>
> It doesn't work. People YOLO experimental features into CPAN and production DarkPAN anyway. Rescinding experimental features becomes problematic. Perl development stalls because progress would break a lot of ill-advised code. This bolsters the public expectation that "experimental" features are safe to use.
>
> I propose that the "experimental" flag be enforced regardless what breaks.
>
> Expectations have been managed poorly. One solution is to take a hard line on experimental features. If the public knows the Porters mean business, they'll stop YOLOing so much, and the flag might work as originally intended.
I agree with this. It's been yelling at users since 5.20 that it's
experimental and they've had to explicitly turn off the relevant
warnings.
John Alvord also brings up a really good point upthread, which is that
our current process (although I don't think this really applies here due
to the aforementioned warning) invites de-facto standardization, from
perlpolicy:
Experimental features must be experimental in two stable releases before being
marked non-experimental. Experimental features will only have their
experimental status revoked when they no longer have any design-changing bugs
open against them and when they have remained unchanged in behavior for the
entire length of a development cycle. In other words, a feature present in
v5.20.0 may be marked no longer experimental in v5.22.0 if and only if its
behavior is unchanged throughout all of v5.21.
I.e. we just say "this might become non-experimental", but we don't hold
ourselves to any sort af an inverse of that policy, i.e. that we must
decide after something has been unchanged in X number of releases that
we're either going to throw it out or make it non-experimental.
May grep-fu may be lacking but:
git grep -C2 -i -e 'given' -e 'smart.*match' -- 'pod/perl*0delta*'
Seems to indicate that there's been no major semantic changes in
given/when since 5.18, i.e. we've had 5.(20|22|24|26) where there's been
no meaningful change to it (and the 5.18 change was tiny).
Hindsight is 20/20, but I think in the future it makes sense to hold
ourselves to reviewing these features once they've been unchanged in say
2 or 3 releases, and for the policy to say that experimental features
unchanged in 3 development cycles must either be promoted to
non-experimental, removed entirely, or have their semantics changed in
major ways.
Thread Previous
|
Thread Next