(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.)
The regressions in Linux kernel upgrades are often a nightmare. Like the recent ACPI regressions in the current kernel. What a mess.
Re:Linux not the best example
jrockway on 2008-09-02T15:37:07
That wasn't a regression. It was a documented deprecation that happened as documented. The fact that nothing in userspace updated for it was annoying, though, I'll agree.
Fortunately, perl won't have that problem since it has a policy of not breaking old code, and people regularly test blead against the entire CPAN.
Re:Linux not the best example
Matts on 2008-09-02T15:44:43
All I know is that the latest linux kernel broke sleep/restore for a LOT of hardware.
Re:Linux not the best example
mr_bean on 2008-09-05T01:58:03
> Fortunately, perl won't have that problem
The desire not to break things slows down the release cycle.
The desire not to break things for other people is a good idea. The slowing down of the release cycle is not such a good idea.
If the porters change their mind about that, what would happen? Would smoking contain the chaos?
Pursuing the linux analogy, what corresponds with the testing distributions like Fedora and debian testing in the perl context?
