Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Sunday November 18, 2007
09:50 PM

Upgrades for those who don't upgrade: META.yml edition.

[ #34927 ]

Over on module-build@perl.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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I heard that story about make, specifically the leading tabs.

  • Firstly, thanks for pointing out there is a discussion about something that is potentially of interest to the WHOLE of CPAN and not just a small subset. Wouldn't it be better to have a specialist list regarding META.yml specs, that discusses these sort of changes? A Module::Build list is not something I am going to sign up as I tear my hair out with MB at the best of times.

    When I first saw your post, I assumed this was part of the Module Authors list discussion a few weeks ago, but struggled to find the th

    • The main issue here is that META.yml is not authorative, with the exception of the configure_requires key.

      You need to run Makefile.PL in order to determine the configuration (and thus dependencies) for that host.

      Thus, META.yml is considered to be advisory only.

      New and useful keys in META.yml are those that are likely to be useful in an advisory context.

      Knowing the minimum Perl version meets this criteria, as useful things can be done by mapping dependencies at a graph level and working out which modules are
    • However, I do think requires_perl is not appropriate, requires_executable using the same format as the requires would be more useful.

      I came to that conclusion, too, but from a desire not to have a whole salad of "requires_perl", "recommends_perl", "test_requires_perl", "configure_requires_perl", etc...

      The trouble is a general purpose executable/external utility specification is a whole lot more difficult. Previously, everything in the META.yml was about the module being shipped. Now we want to specify thi
  • I find it more bizzare that it starts of with

    "After a number of incidents, it would appear that putting the Perl version dependency into requires is
    just too problematic to be an appropriate solution."

    but doesn't mention any of these incidents.