develooper Front page | perl.perl5.porters | Postings from September 2011

Re: Perl 5.16 and Beyond.

Thread Previous | Thread Next
From:
Dave Rolsky
Date:
September 14, 2011 07:36
Subject:
Re: Perl 5.16 and Beyond.
Message ID:
alpine.DEB.2.00.1109140926540.9044@urth.org
On Wed, 14 Sep 2011, Dave Mitchell wrote:

> I think the devil is in the detail. If, while running under 5.20,
>
>    use v5.16;
>
> is just about equivalent to
>
>    no feature 'list of features added in 5.18, 5.20';

I think that realistically, it will have to be somewhere between this and 
"acts exactly like 5.16 in all ways".

I think each backwards incompatible change will probably need to be 
considered on its own as a candidate for this policy.

I think there are several categories of backwards incompatible changes.

For bug fixes, I think we may just ask people to bite the bullet and 
accept the change. It seems unrealistic for anyone to expect us to provide 
infinite bugwards compatibility.

For additions of new features with new keywords, this use line will block 
the new keywords from being usable in that scope. This seems fairly easy, 
for some value of "fairly" and "easy" which I can't speak to, since I've 
never hacked on the core C code ;)

The real question is when we change the behavior of existing features. The 
smartmatch operator is a good example. It seems that p5p widely agrees 
that the existing behavior is a mess and needs to be cleaned up. However, 
this behavior has been documented for a number of versions, so preserving 
the old behavior as an option seems like a great idea, if we can do it 
(and apparently we can).

What about things like updating the Unicode database? That's not a bug 
fix. But does it really make sense to ship every version of Unicode that 
we've ever documented as support? Isn't getting a new version of this 
database one of the reasons to upgrade? I think this is where things get 
sticky.

I also wonder if there will be a sunset on maintenance of these old 
features. At what point might we consider removing a smartmatch 
implementation from core? How many implementations would we be willing to 
maintain?


-dave

/*============================================================
http://VegGuide.org               http://blog.urth.org
Your guide to all that's veg      House Absolute(ly Pointless)
============================================================*/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About