chromatic has been discussing the idea of an "official" support policy for Perl 5.
Like a few other topics, we disagree on how long that should be
He seems to like a number of somewhere around a year, whereas currently I base my (loosely held) preference on what I think Perl needs to provide to be compatible with business usage (where far more Perl programming is done compared to the open source world) on an internal SAP survey that asked customer CTO and CIOs what their preferred upgrade rate was for ERP systems.
The survey reported that they preferred to upgrade their ERP system "Every 8-10 years, on a Saturday afternoon".
Clearly this is an idealised position, but Perl is indeed very stable and business friendly, and it does currently hold to somewhere around that rate.
For example, the CPAN toolchain (which is probably the biggest driver of back-compatibility) recently abandoned 5.005 (10 years old) and moved to a new Long Term Support target of Perl 5.6.2 (5.5 years old). In practical terms we also unofficially support 5.6.1 as well (8 years old last month), so anyone using 5.6.1 is probably ok as well.
The main caveat is that anything involving Unicode is going to have a much higher Perl 5.8.5 dependency (4.75 years).
If we consider 10 years to be too long to be a practical target, and anything less than a year to be too short to be a practical target, we have a reasonable bounding range within which to make a decision.
And for such an important decision, we need to find a robust decision making process.
While opinion, debate and blog posts at 10 paces can be great for making negative decisions (ruling out a particular option as bad) it's not always the best way to make positive decisions (picking the optimal solution).
We need to see if we can find a data-driven method. The CPAN is a good starting point, but insufficient. And the DarkPAN (All of the Perl code out there that isn't in the CPAN) is inherently unknowable.
But in recent years, with the growth in publically-accessible repositories as the default, we're seeing the formation of an new and interesting strata of the DarkPAN that I'm going to boldly term "The GreyPAN" (unless someone has already come up with a better term and I didn't notice).
In a recent post to the Ohloh Forums, I noted that Ohloh was reporting a far larger number of "lines of Perl" than I might have expected, and I was frustrated by not being able to find out exactly where all of this code was.
While a few million lines are concentrated in prominent non-CPAN projects like WebGUI and Twiki/FOSWiki, the vast majority are spread out in all sorts of different projects, doing the same utility tasks Perl does everywhere in the business world as well.
If this is the case, then it seems reasonable that we can take the GreyPAN as a analogue for the structure and consistency of the DarkPAN (or at least, for the region of the DarkPAN created over the last 5-10 years, when most of the Open Source code in the GreyPAN repositories were created.
And since we have tools for parsing useful information about Perl code (and doing Perl version dependency analysis in particular) it seems fairly reasonable (albeit computationally expensive) that we could do a metrics run on all of THAT Perl code and get a feel for how much damage we cause by moving the "minimum supported version of Perl" up to a newer version.