If, on the other hand, it won't work simply because the author decided to require some fancy, superficial feature like say....

"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?" — Larry Wall

One person's superficial triviality is a feature that's been in Perl for more than six years now. How long before it's acceptable for volunteers who give away their code freely to use those features? Ten years? Fifteen? If I fix a bug in Perl today and it gets released in 5.20, will I be able to rely on that bug being fixed by 2024? 2029?

You don't have to upgrade Perl, but you don't have to use any modules I've written either. Even better—you don't have to use them as written. You are more than free to modify them to run on your preferred version. I'll even give you a comprehensive test suite so you can prove that they work to your satisfaction. You can even redistribute the modified version.

Is that not enough?

I have to admit I don't know exactly who wrote each and every module I use, and I'm very happy that this isn't (yet) a big enough problem to cause great concern and personal discomfort.

I'm just saying that if a critical component like DBI or LWP broke on RHEL/CentOS 5 tomorrow because someone wanted to use new and shiny features to golf the code down a bit, I think you'd see a sharp decline in the popularity of Perl.

Bug fixes are ofcourse a completely different subject. Anyone who writes production code that relies on a bug to function properly should have their keyboard privileges permanently revoked.

-- FloydATC

Time flies when you don't know what you're doing

someone wanted to use new and shiny features to golf the code down a bit

The people who pay me need working Unicode. I don't have to release parts of that code so that you can use, modify, and redistribute it without paying me, but I do.

(Come to think of it, no one who's contributed to Perl itself in the past six years has charged you a penny to use it.)

Do you intend for your comments to sound condescending and insulting?

A faster regular expression engine is only good for golf? Working Unicode is only good for golf? A regular expression engine without recursion crashes is only good for golf? Memory optimizations are only good for golf? Self-recursive functions without memory leaks are only good for golf? Native casefolding is only good for golf? Fixed memory leaks are only good for golf? DoS-safe hashes are only good for golf? A working keyword extension mechanism is only good for golf?

Do you really mean to give the impression the only reason someone would use anything newer than 5.8 is because he or she thinks adding "\n" to the end of every print is onerous?

There now is a "consensus" of what the minimum version of perl is to be supported for the major modules on CPAN (amongst which is DBI). The consensus today is 5.8.1, with an option to move to 5.8.4 when the need arises.

The fact that a new version of any of those important modules starts using a new(er) feature that will require a newer version of perl does NOT mean that the previous version of the module suddenly stops working.

The module authors are very well aware of OS's that stick to old(er) versions of perl, but sometimes it is hard to stick to cruft to make a module build on those old platforms or OS's. A reason might be that a compiler is buggy. That buggy compiler also does not get updated/upgraded on that old system, so why would you update a perl module that behaves well?.

Once you update the OS, you also probably get a newer version of perl and your problem is gone. If you don't use system perl, nothing is stopping you installing a newer version of perl alongside the system perl.

As most modules have public repositories nowadays, nothing is stopping you to backport bugfixes that affect you to the now unsupported ancient environment.

I for sure do NOT foresee a sharp decline when module authors start declaring 5.8.4 as a minimum.


Enjoy, Have FUN! H.Merijn