(Originally posted to p5p and inspired by Re: forcing older perl to use an older version of cpan module?, by Nicholas.)

Maybe it's possible to solve [the problem of businesses having trouble upgrading Perl installations and the lack of volunteers supporting Perl 5] by giving up the polite fiction that the feature-based release process works.

If you (not Nicholas) think it works, answer me this question: with eight months of bug fixes and updates and patches to bleadperl, will 5.10 magically become "stable" and not "testing" only when someone works out the proper given/when semantics? As far as I can tell, that's the main work standing in the way of a 5.10.1 release, at which point people start to believe that they should use 5.10 instead of 5.8.

Answer me this: if you believe that the best upgrades are infrequent upgrades, why do you update your source tree right before you make a new change?

Answer me this: what happens when someone asks "Why is argument unpacking so much slower in 5.10.0 than in 5.8.8?" and no one can point to a vendor backporting patches aggressively and the best answer there is is "There's a fix in what will become 5.10.1... eventually... someday"? (Guess how the backport avalanche begins.)

Most of all, answer me this: why does the oft-proposed solution to the problem that "It's difficult to upgrade Perl and its ecosystem" include slowing things down and throwing money and time and talent at boring, manual slog-work of verifying that mountains of changes in once-in-a-blue-moon big bang big thud releases work? Why not make upgrading Perl so simple and easy that it's boring and easy to automate because it's frequent, reliable, and repeatable?

In return, I'll answer two questions premptively, for free.

1) It's possible because the Linux kernel does it -- and if you want a project that's larger and older than Perl 5, has orders of magnitude more changes, and is very possibly more widespread, there's your example.

2) The reason to upgrade every month or two months or three months is because bleadperl is better than it was three or two or one month(s) ago. (If it's not, that's a different problem, and we should probably stop developing Perl if we can't fix that.)