Front page | perl.perl5.porters |
Postings from December 2017
On Sun, 31 Dec 2017 00:37:56 +0100 Ãvar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > Okey, then we patch perlpolicy.pod to say: > > diff --git a/pod/perlpolicy.pod b/pod/perlpolicy.pod > index 6c57238eac..dfcf0432f6 100644 > --- a/pod/perlpolicy.pod > +++ b/pod/perlpolicy.pod > @@ -248,6 +248,12 @@ no longer ship with Perl, but will continue to be available on CPAN. > > =back > > +=head1 CAVEATS > + > +Oh and by they way, if something's sufficiently complex or widely > +used, forget about everything we mentioned about > +experimental/deprecated/etc. above, it's staying, B<forever>. > + > =head1 MAINTENANCE BRANCHES > > New releases of maintenance branches should only contain changes that fall into > > Which, to be clear, is I'm not taking a particular stance on these > given/when changes, but saying that we should decide, in general, how > the policy applies to changing such long-standing features. > > Maybe the answer should be "it doesn't change", or maybe the answer > should be "suck it, take Zefram's patches", regardless of what any of us > think about those patches this discussion points to the fact that we > need to patch perlpolicy.pod to describe these situations more > generally. perlpolicy already covers that: Existing syntax and semantics should only be marked for destruction in very limited circumstances. If they are believed to be very rarely used, stand in the way of actual improvement to the Perl language or perl interpreter, and if affected code can be easily updated to continue working, they may be considered for removal. When in doubt, caution dictates that we will favor backward compatibility. When a feature is deprecated, a statement of reasoning describing the decision process will be posted, and a link to it will be provided in the relevant perldelta documents. Also, I didn't say we shouldn't touch smartmatch. To be frank, my point was that new smartmatch sucks and we need to rethink it. > How are we going to handle the next new feature that gets introduced in > 5.30, gets marked as experimental in 5.40, and someone wants to change > in 5.48? I'm pretty sure we will never retroactively mark feature as experimental ever again.Thread Previous | Thread Next