Over on firstname.lastname@example.org there's a bizarre argument going on over changing how you declare the minimum version of perl in META.yml. Currently it's an ambiguous, undocumented special case of the "requires" mechanism which is supposed to only be for modules. Folks want to make it it's own key.
The bizarre part is folks are blocking this as a backwards compatibility thing. That if we add a new key to META.yml those using old tools won't be able to parse it. David Golden put it this way...
> CPAN author: "Why are you complaining that my module doesn't work on
> 5.6? I clearly put 'requires_perl' in the META.yml"
> CPAN user: "My $job still uses 5.6.s and doesn't let us install newer
> versions of @toolchain_modules"
As to this, I'll paraphrase chromatic. Why are we worrying about the effect of upgrades on users who don't upgrade?
Hell, we're not even saying "upgrade perl", which can be a major event. We're just saying "upgrade some toolchain CPAN modules which we've painstakingly released separately from perl itself and ensured still run on your seven year old version of perl". Come on, meet us halfway here. Quarter of the way? Can you at least come down at meet us at the door?
Paradoxically, the more we bend over backwards to support users who are being blocked from upgrading, the harder it is for them to upgrade. Huh?
I've been in that situation where $job won't allow an upgrade. Usually the problem is that $job doesn't want the programmers spending time (and thus, money) on a task which they perceive as having no business value. Thus the programmers must justify the upgrade in terms of business value. For example, if the company decides to start doing work in Japan you might cite the improved Unicode features of 5.8. Barring a home run like that, what's left?
The constant problems installing new CPAN modules on old perls is one. Every time you have to patch around incompatibilities with your old perl a little bit of money goes *poof*. Add them all up and you've got a business case for upgrading perl.
But what it really boils down to is this: Who's more important: Some users who won't upgrade or all your future users? How many future users are you willing to inconvenience (and possibly lose) to avoid inconveniencing those who won't even keep up to date? Backwards compatibility is important, but there's a limit to how far you should drag people along who don't want to go. Not at the expense of moving forward, always improving.