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.
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?
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.
Re:The problem is...
chromatic on 2007-10-16T05:17:10
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.
Re:One more thing...
chromatic on 2007-10-16T04:59:49
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 dime to maintain Perl 5.6.1 either. Maybe someone is through ActiveState, but that's ActiveState's problem, not mine.
Frankly, I'm more than a little tired of the unmitigated ingratitude from people who somehow think it's perfectly acceptable to moan about software designed, written, tested, and released for free, under an exceptionally free license. If, after twelve stable releases, you still can't bring yourself to upgrade, you've given up your right to demand anything from the contributors to the software. Fork and maintain it yourself.
Re:One more thing...
Alias on 2007-10-16T06:04:48
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 of their systems.
Less than 20% of Perl programmers are using 5.8.8.Re:One more thing...
chromatic on 2007-10-16T06:40:01
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?
Re:One more thing...
sigzero on 2007-10-16T11:56:08
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).Re:One more thing...
chromatic on 2007-10-16T16:07:15
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 have a Red Hat 7 box I've been trying to migrate users off of for nearly a year. By the time they start to move on their own, it'll be time to upgrade to another version of Ubuntu LTS, despite the fact that we've been hand-rolling new versions of the software on the RH box to fix security vulnerabilities for years.
I don't particularly mind if some organization wants to get off of the upgrade train and handle security fixes and bug fixes and routine maintenance itself. That's fine. Forcing the rest of the community to handle that, though, is not okay.
Re:One more thing...
sigzero on 2007-10-17T11:45:33
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.Re:One more thing...
chromatic on 2007-10-17T17:27:34
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.
Re:MySQL
Aristotle on 2007-10-16T14:45:01
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 having to issue an ever-expanding set of “yes, I want sane behaviour” pragmata like the strict mode in 5.x, which finally allows you to keep the damned thing from mangling bad data to fit constraints and then happily storing the resultant muck without complaint.
Meanwhile, MySQL advocates love to point out the things it has that PostgreSQL lacks – as if PostgreSQL wasn’t subject to the same progressive improvement that MySQL is. (8.3 is coming up soon, btw!)
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 more favourable.
Supporting earlier versions of Perl is easy as long as you don't need features supported only in later releases. You seem to have lost view of what Perl features are necessary for your module and propagate the meme of blindly slapping an arbitrary Perl version requirement number onto your module without further thought. Instead of being lenient and allowing users to use your module if it works for them, you try to be strict and enforce your views of practicability on what you call leeches.
For example, I use Perl at work because it's there. Every Windows(!) machine here has some version of AS Perl installed. Installing my own Perl would be too much hassle and against company policies, so I have to work there with what I got. Mandating some cut-off Perl version wouldn't be a major obstacle for me, because I've backported stuff to 5.004. Others who use Perl as a tool of getting things done instead of Perl as a religion/way of life would be cut off from using Perl. I guess you want to express your attitude that you want only to work with the proud who stand up for Perl and fight the Good Fight to establish a Proper Perl Environment. I feel you are overlooking that there is a trade-off between the practicability of Perl and the efforts consumed by a fight for a Proper Perl, especially if your job title does not contain the word "programmer".
I'm not sure why you are on a crusade to expunge backwards compatibility and backwards maintenance from Perl, CPAN, or your modules. It's not as if the maintenance of old Perl versions came out of your paycheck. Unless O'Reilly needs to sell new books for new versions of Perl and people still do too well with the warez copies of Perl4 and Perl5 on the internet. Which would also conveniently explain why Perl6 needs to have a vastly different syntax.
Re: Cutting Off the Leeches
Aristotle on 2007-10-16T15:00:13
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
openand multi-argument (non-shell) pipedopen. 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 compliant with 5.5, possibly with even more ancient versions.
Re: Cutting Off the Leeches
chromatic on 2007-10-16T15:57:52
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 Perl and people still do too well with the warez copies of Perl4 and Perl5 on the internet. Which would also conveniently explain why Perl6 needs to have a vastly different syntax.I'm not sure anyone would call the Perl book gravy train lucrative. This would be a better conspiracy if O'Reilly had released several versions of the camel for various versions of the Perl 5.8.x series (or had plans to produce one for Perl 5.10.)
From Perl::MinimumVersion
Alias on 2007-10-17T01:56:50
Although personally I generally consider unicode as 5.8.5 rather than 5.8.0# 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'),
