Slash Boxes
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 ]

chromatic (983)

  (email not shown publicly)

Blog Information [] Profile for chr0matic []

Journal of chromatic (983)

Monday October 15, 2007
08:47 PM

Cutting Off the Leeches

[ #34685 ]

A lot of people say that PHP is a nasty language because PHP had register_globals on by default through PHP 4 sometime. (PHP 6 is in development.)

A lot of people say that MySQL is a terrible database because version 3.23 did not support transactions. MySQL 5.1 is nearing release.

Downstairs there is an iMac of the aquarium-style, with perhaps 64 MB of RAM and a G3 processor, at best. It doesn't run Mac OS X very well, if at all. Note that current Macbooks use multicore Intel processors.

By my counting, Perl 5.6.0 is twelve stable releases old.

  1. 5.6.1
  2. 5.8.0
  3. 5.8.1
  4. 5.8.2
  5. 5.6.2
  6. 5.8.3
  7. 5.8.4
  8. 5.8.5
  9. 5.8.6
  10. 5.8.7
  11. 5.8.8

Good luck getting support for a software package twelve stable releases old. Ubuntu GNU/Linux hasn't even had twelve stable releases. Neither has Debian. Twelve stable releases ago, Red Hat hadn't subsumed Fedora.

Twelve stable releases ago Windows was at ... well it was before Windows 95, unless you count service packs.

Why would someone not upgrade from Perl 5.6.0?

  1. The user doesn't upgrade software at all.
  2. The user is comfortable supporting the software at its current level him or herself.
  3. The user is incompetent.

It's completely useless to write new software or to produce upgrades for cases one and three. That should be horribly self evident.

I can't see how it's worth my time to write new software or to produce upgrades for the second case, either. If code I write doesn't miraculously work on ancient versions of Perl (Did I mention that 5.6.0 is twelve stable releases old? Dare I mention that some popular modules even eschew the use of lexical filehandles, and who wants to go back to those old days?), then anyone willing to support ancient versions of Perl has either skill or the extreme self confidence to backport my software him or herself. The license allows it. Go crazy (or crazier).

I'm about >< close to slapping require 5.8.3; in the Build.PL of all of my CPAN distributions. Anyone who really, really, really needs to run a version of Perl almost four years old or older ought to be able to fix any problems.

If not... well, I don't take responsibility for people who make toast, fax their CVs, and blow dry their hair while taking a bath either.

Before you hit Reply and call me all sorts of names for adding features and fixing the occasional bug and writing a fair few tests in Perl and actually wanting to take advantage of that work for which I've never received a penny, let me point out that my actual preference is to recommend that p5p not support any version of Perl older than two years. That would be 5.8.7.

If you have code that depends on one of my modules, feel free to fork and bundle my code. Consider this fair warning. Just don't expect me to waste my time supporting ancient versions of Perl. The code's there, it's free, it's freely modifiable and redistributable, even if you want to do something incredibly, amazingly stupid with it... like supporting a release of Perl that's twelve versions old. If you do that, I'm not accepting bug reports though. It's on your head.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • ... that you don't let OTHER people backport your code either.

    You can't just fork modules.

    If AUTHOR/Some-Module-0.01.tar.gz depends on CHROMATIC/Some-Other-1.00.tar.gz and your module is 5.8.3, that makes the OTHER modules 5.8.3 too, and there's not a goddamed thing the person two or five levels of dependency down the line can do about it.

    So that leaves either:

    1) EVERY SINGLE PERSON that wants to use something you have written individually backporting everything of yours they use and using non-CPAN ugly for
    • If someone wants to make one of your modules back-compatible and is willing to maintain it, why not let them look after it instead.

      Perhaps if I never intended to update the module ever again, I would. I'm not sacrificing the future for the sake of people who don't upgrade, though.

  • I'll also add that I personally consider the ideal back-compatibility point to be 10 years, which is the length of the longest common support contract currently in use (typically by governments).

    Which, I believe, is currently somewhere around about 5.6.1?
    • 10 years ... is the length of the longest common support contract currently in use (typically by governments).

      If your rate card has the appropriate values such that you think it's a good trade of your valuable time for the sheer pleasure of supporting Windows 98-era software, fine. However, I completely fail to see why I should care about the length of someone else's support contract, when I don't get one red, black, blue, green, pink, or paisley cent from it.

      I'm pretty sure no pumpking's getting a d

      • Windows is a different area, since support issues on Windows in general align with the support issues to do with Windows itself.

        The money issue is irrelevant, since most people for the most part don't get money to work on ANY version of Perl or CPAN modules.

        As for forking, you can't fork dependencies.

        As an alternative, take a look at the results from the Perl survey.

        If you, for example, only support 5.8.0+, that means 30% of all Perl programmers (subject to survey bias) can't use the module on at least one
        • Windows is a different area...

          Not even Microsoft supports Windows 98 for free. Why should anyone support Perl 5.6.0 for free?

          The money issue is irrelevant...

          You brought up government support contracts.

          Less than 20% of Perl programmers are using 5.8.8.

          Perl 5.8.8 is nearly 21 months old. Perl 5.8.7 is almost 29 months old. Perl 5.8.6 is almost 35 months old. If people haven't upgraded to stable point releases in three years, what in the world makes you think they'll upgrade modules?

          • I don't upgrade because:

            1 - It is working fine
            2 - There is no budget to do any type of re-write

            I would really love to move to 5.8 as there are a lot of modules that I could use to get rid of the hand made cruft. Sadly, it probably isn't going to happen (we actually have a big meeting about it in November).
            • That's exactly my point. Consider the security patches put out for the printf problem a couple of years ago. How long did it take to make a patch for each patched version of Perl? I can see supporting the last couple of versions, perhaps with a support window of two years, but any organization that distributes an older version of Perl ought to be able to backport security patches, or else support its users.

              It's not as if anyone reasonably expects Adam Kennedy to support File::Remove [] 0.37 now, either.

              • I actually wasn't suggesting that 5.6.0 should be supported. I was just saying I can't upgrade at the moment. I wonder if I could drop in 5.6.2 without a problem.
                • Unless your code relies on specific 5.6.0 bugs that are not present in 5.6.1, you should be able to upgrade almost trivially. 5.6.2 is basically 5.6.1 with a couple of changes in the configuration/compilation process to build cleanly on modern systems.

  • A lot of people say that MySQL is a terrible database because version 3.23 did not support transactions. MySQL 5.1 is nearing release.

    In case anyone thinks "Ovid" when they read that, I loathe older versions of MySQL for being pieces of junk and I hate the fact that I have to work on it. I don't automatically think that 5.x is crap just because < 5.x is crap. The 5.x series is becoming tolerable.

    • 5.x still does not support transactions – if you use the MyISAM engine, which is all there was in 3.x. It’s just that you now have the choice to use a storage engine that – surprise!! – is a lot slower… but also a good deal less crappy.

      However, that doesn’t fix all the other insane cruft in MySQL, like the quantum superposition of NULL with 0000-00-00 dates and empty strings, and like issues. And I don’t see how they could fix those without new client applications

  • Insulting your userbase is always a great technique inspiring confidence.

    You act as if there were an actual burden placed upon you by the unreasonable demands of the masses. In my experience, the main thing that breaks with modules when moving to older versions of Perl is the test suite and little else. If you show us the examples where supporting an older version of Perl places an unreasonable burden, performance or maintenance wise, or even aesthetically, I'm sure your point of view could be received mor

    • If you show us the examples where supporting an older version of Perl places an unreasonable burden, performance or maintenance wise, or even aesthetically

      Personally I absolutely refuse to downgrade any use of three-argument open and multi-argument (non-shell) piped open. I also don’t care to expend the effort to operate without proper Unicode support. The former draws the line at 5.6.0, the latter at 5.8.1.

      Where those two aren’t an issue, though, I would have no problem making my code com

    • I'm not sure why you are on a crusade to expunge backwards compatibility and backwards maintenance from Perl, CPAN, or your modules.

      I'm trying to figure why in the world I spend time adding new features to software, fixing bugs in software, and writing other software that relies on the new features and the bug fixes if every time I release that free software, people complain because it doesn't work on software released years and years ago!

      Unless O'Reilly needs to sell new books for new versions of Per

  • I agree: it's completely obnoxious when people demand that I make sure Foo::Bar support 5.004. If their demand is accompanied by a patch, that's one thing, but when it's a vague "I really need your weird new features, but I really can't ever upgrade perl itself, so help me" I have to wonder what kind of wolves raised them.

    I aim for 5.6, when possible. The new features in 5.8 were not, on the whole, really useful for day to day things for me, so I don't tend to need 5.8 unless a prereq does. I've kept Ema
    • # Various small things
        _bugfix_magic_errno   => version->new('5.008.003'),
        _unquoted_versions    => version->new('5.008.001'),
        _constant_hash        => version->new('5.008'),
        _use_base_exporter    => version->new('5.008'),
        # Included in 5.6. Broken until 5.8
        _pragma_utf8          => version->new('5.008'),

      Although personally I generally consider unicod

  • I'm about >< close to slapping require 5.8.3; in the Build.PL of all of my CPAN distributions.

    Yeah, that will teach a lesson to those people that never upgrade and will never see that you slapped a require 5.8.3 in there. You sure showed them. You master of cunning you.
  • We've got a huge base of 5.6-dependent code which we cannot upgrade to 5.8 because we implemented our own Unicode handling when perl's was a joke. Now 5.8 has good Unicode but it breaks our own custom one in about a million places. Just an example of why I frequenly send patches of -use 5.8;