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 ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/
Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Tuesday October 16, 2007
12:31 PM

It's *Major* Releases that Matter

[ #34696 ]

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.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

It's *Major* Releases that Matter 16 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Supporting 5.6.2 is basically the same as supporting 5.6.1: the only real changes are a few dual-lived modules and that the build system was updated for some newer compilers.
    --
    rjbs

    • 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.

      • 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
        --
        rjbs
  • 5.6.2 is a decent version to depend on, although I believe Schwern has mentioned that 5.6.1 is the sweet spot at the moment in terms of what people are actually using.

    And I think we can all agree that there's no need to support 5.6.0.
  • A module that I need to run a script identically via SSH on all hosts via 'perl -I ~/lib/perl ' command will have to be 5.005_03 compliant, sadly.

    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. [On these systems, we set "alias" for perl56 and perl58 to our locally built perl's - installed if the app uses them.]

    Applications can bring their own copy of perl with them (with DBI bindings or other XS modules), but
    --
    Bill
    # I had a sig when sigs were cool
    use Sig;

    • 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.

      • > 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

        • 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 upgra

          • 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.

            • ... 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?

              • 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

          • > 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 f

          • 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 b

            • 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

              • 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, f

                • 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.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.