I realized this morning that my metric in Cutting Off the Leeches was wrong. I see Perl 5.8.7 and Perl 5.8.8 as different major releases because of the Perl 5's development model.
Anyone else who thinks that is probably also on p5p.
After realizing that, I now find it reasonable to support the latest point release of the previous stable major version of Perl, as well as the current stable major release. Instead of Perl 5.8.3 (and instead of using its age as the cutoff point), my new oldest supported version is Perl 5.6.2.
Now if a module or distribution needs a new feature only present in a later version, I'll mark that specifically... but I can live with supporting Perl 5.6.2 (almost four years old) until Perl 5.10 comes out.
Re:5.6.2
chromatic on 2007-10-16T20:25:58
It's not about features, else I'd pick the exact release where the code as written stops working. It's about what I'm personally willing to support, for free.
Re:5.6.2
rjbs on 2007-10-16T21:27:53
For me, that's both. I'll put "use 5.006" in the Makefile.PL. Then, if I see FAIL results that I can tell are because of 5.6, or that never occur with 5.8, I do one of two things: I decide, "those look fun, I'll fix them," or I decide, "oh well, time to bump up the perl requirement."
I haven't yet felt pressured into setting some kind of firm limit below which I won't support. If I got a sufficiently-fun-looking bug report for 5.005, I'd probably investigate it. If I got a really tedious bug report for a complex problem for 5.8.5, I'd probably change the required version to 5.8.6.
Re:5.005_03 is still Reallity for many sysadmins
chromatic on 2007-10-17T17:32:25
Solaris / SunOS 5.8 aka 8 is still widely deployed and supported, even though Solaris 9 and 10 are out there. Sun provides/usr/bin/perl 5.005_03. I had just started to write Perl in March 1999. If Sun wants to support an eight-and-a-half-years-old versions of Perl, talk to them about updates. Presumably you're paying them $$$ for a reason.
Honestly, sysadmins are as much the problem here as anything.
Re:5.005_03 is still Reallity for many sysadmins
jhi on 2007-10-18T03:20:02
> I had just started to write Perl in March 1999. If Sun wants to
support an eight-and-a-half-years-old versions of Perl, talk to them about updates. Presumably you're paying them $$$ for a reason.
>
> Honestly, sysadmins are as much the problem here as anything.
You really should get out more often.
Many environments/setups demand/require/dictate stable software installations. (Yes, I'm aware of my.sig line.) And this has often nothing to do with anyone in particular being lazy and/or resistant to upgrading. The *stability* of the *whole* system is what is at stake. You just CANNOT go around upgrading components since that may have grave consequences in other parts of the environment.
I can't say that I subscribe to this "fuck off, lazy fucker" school of attitude towards potential users. Of course, anyone is free to choose their user base, and the grace they show choosing it.
Re:5.005_03 is still Reallity for many sysadmins
chromatic on 2007-10-18T06:13:58
You just CANNOT go around upgrading components since that may have grave consequences in other parts of the environment.... except, apparently, for my CPAN modules, as evidenced by all of the pissing and moaning about how I'm so irresponsible, so inexperienced, and such a misanthropic bad person because I don't care that new code doesn't run on versions of Perl released last millennium.
That's the part I don't get. If you don't upgrade software, why complain that the software you're not going to upgrade to won't run with the software you won't upgrade?
Re:5.005_03 is still Reallity for many sysadmins
Corion on 2007-10-18T06:49:33
This affects new installations of programs or tools using the old Perl. And yes, like Windows, Solaris does not come with a C compiler by default, and more to the point, we have lots of machines where the C compiler is explicitly not installed. Installing a CPAN module there is of course still possible as long as it does not use XS, either with cat >perllib/Some/Module.pm through a terminal session or by doing the traditional perl -w Makefile.PL dance, but compiling your own Perl is out of the question. So you got to live with the system Perl, whichever that is.
Of course, old, compatible versions of modules might be available on the backpan, but being backwards compatible means that I can use a module regardless of the underlying Perl. Without needing to remove all lines that use warnings; or use 5.008; just because some [ft]ool running under 5.8 put these into the template.
Again, personally I prefer lexical filehandles over localized globs, but if that were the only thing preventing one of my modules from compatibility with 5.005, likely I'd pull in the code from Symbol to cater to my user instead of telling them that they're leeches. But I guess name calling is par for the course with free software.
Re:5.005_03 is still Reallity for many sysadmins
chromatic on 2007-10-18T08:03:57
... compiling your own Perl is out of the question. So you got to live with the system Perl, whichever that is. I left system administration in 2000, but even I still remember sunfreeware.com, and then there's ActiveState and Strawberry Perl, and Merijn's packages, and plenty of other places to get modern versions of Perl without disturbing the system Perl.
Again, this is the part I just don't understand. Why are you installing new software (or upgrading old software) on a system you consider stable? If you consider Perl 5.005_3 stable and all of the software on the box stable and you don't want to mess with those, why does it matter if the latest version of Test::MockObject won't run on Perl 5.005_3?
Contrarily, if you really do need new versions of libraries or tools or whatever, why are you not upgrading the rest of your software to supported versions?
... some [ft]ool running under 5.8 put these into the template.... But I guess name calling is par for the course with free software. I hope that was deliberate irony.
Re:5.005_03 is still Reallity for many sysadmins
Corion on 2007-10-18T08:31:44
Contrarily, if you really do need new versions of libraries or tools or whatever, why are you not upgrading the rest of your software to supported versions?For the same reason that I don't build a new house just because I need a new light in a room. I use Perl as a tool to get a job done. I think that's where our difference in point of view comes from. You seem to see the Perl program as an end to itself and hence the environment must be made to fit the program. I see the job to be done as the central point, and whatever Perl there is will need to suffice as my tool. If it is more hassle to hunt down the prerequisites and to fix the compatibility breakers with 5.005_03 (or whatever Perl I have available - conveniently Solaris 10 now has 5.8.4, which OSX has too) than to manually fix my data or to write a script myself from scratch, that makes any module unusable for the solution.
I also know sunfreeware.com and I have a system administrator who kindly installs many things from there on certain machines. But even then, these packages cannot be installed as a normal user, so it's still a major hassle to get something tested and deployed just for a small tool built from some modules.
Re:5.005_03 is still Reallity for many sysadmins
jhi on 2007-10-18T18:28:46
> That's the part I don't get. If you don't upgrade software, why complain that the software you're not going to upgrade to won't run with the software you won't upgrade?
It's not that hard a scenario. They may not be able to upgrade the system Perl, or install a newer one, but they may want to use CPAN modules, or some software that they use and *can* upgrade, requires CPAN modules.
(Of course, one problem is that by default e.g. CPAN.pm wants to install the latest and greatest version. Which is good for getting bugs fixed, but a bad idea for features from future kicking you in the groin.)
Re:5.005_03 is still Reallity for many sysadmins
Alias on 2007-10-29T23:50:06
as evidenced by all of the pissing and moaning about how I'm so irresponsible, so inexperienced, and such a misanthropic bad person because I don't care that new code doesn't run on versions of Perl released last millennium.
I believe we agree'd a while back that the correct word was "selfish".:)
And you are, but this isn't necessarily a bad thing.
Certainly, for new modules there's really not that big a deal with whatever minimum version you want.
The problem comes from the big rule of legacy support "Don't break stuff that works".
What gets people annoyed is when something CURRENTLY works on 5.005 or whatever, and then the module gets updated to more modern practices (when these changes are NOT required to fix a critical bug) and suddenly stops working for what they see as no good reason.
This is, of course, compounded by people that use modules as a dependency and target similarly old versions of Perl themselves, only to find their minimum version is now bumped up as well by a dependency or a dependency of theirs.
Again, not a big deal for new code, but very important for old code.Re:5.005_03 is still Reallity for many sysadmins
chromatic on 2007-10-30T00:26:34
What gets people annoyed is when something CURRENTLY works on 5.005 or whatever, and then the module gets updated to more modern practices (when these changes are NOT required to fix a critical bug) and suddenly stops working for what they see as no good reason.Some of those modern practices have really solid reasonings behind them, such as lexical warnings and lexical filehandles.
Again, I ask you, why do you think that people who haven't updated Perl to a version released in the past eight and a half years will upgrade to a module for any reason except perhaps a critical bug? (Isn't Perl 5.005 vulnerable to the
sprintfproblem?)Shouldn't these mythical people have paid support contracts if their business relies so much on stability? I don't see any patches coming out of p5p for anything older than 5.6.2.
Re:5.005_03 is still Reallity for many sysadmins
Eric Wilhelm on 2007-10-30T07:08:23
Either it is a potential for a lucrative business or just a lot of noise. If the former, I'll happily create a frozen+backports CPAN and start billing subscribers (in thousands per month) and paying porters (in hundreds per hour.)
If it's just a lot of noise (which seems likely since a frozen index would be rather trivial to create), then I fail to see how it contributes to Perl, CPAN, or the community.
It might be free software, but it is still a market economy. You either solve the problem yourself, form a group which mutually benefits from the solution, or write a check to someone who solves it for you.
Re:5.005_03 is still Reallity for many sysadmins
chromatic on 2007-10-30T16:13:11
You either solve the problem yourself, form a group which mutually benefits from the solution, or write a check to someone who solves it for you.All of those options are fine with me. Complaining when someone who works on this as a hobby and who doesn't share your goal of enabling people to do something he considers stupid and risky and expecting him to do your paid work for you is not okay.
