Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Arguements for upgrading from Perl 5.8

by dlarochelle (Sexton)
on Nov 17, 2011 at 19:07 UTC ( #938667=perlquestion: print w/ replies, xml ) Need Help??
dlarochelle has asked for the wisdom of the Perl Monks concerning the following question:

Our production server runs Ubuntu 8.4 ( Hardy ) and as such we're stuck with Perl 5.8.

I use Perl 5.10 on my development machine but cannot use 5.10 features since the code must run on the 5.8 production machine.

I would really like to get the production machine moved to 5.10 but I'm having trouble convincing my managers and sys admins.

Possible issues with upgrading perl are:

  • that we use over 200 CPAN modules
  • the Ubuntu Hardy repos only contain Perl 5.8 so we'd have to either upgrade to Lucid or install Perl locally.

What arguments could be used to justify an upgrade like this?

I'd like something more substantive that vague ideas about cleaner code and newer features.

Also any ideas about clean ways to upgrade a production machine like this?

Thanks in advance.

Comment on Arguements for upgrading from Perl 5.8
Re: Arguments for upgrading from Perl 5.8
by davies (Vicar) on Nov 17, 2011 at 19:19 UTC

    As I understand it, the Perl used by the system and the Perl used by other code need not be the same and it can be a very bad idea to change the system Perl. Now, I'm a Losedows user, so take this with more than a pinch of salt until it's confirmed by someone who knows more.

    It's certainly possible, on any operating system that has the disc space, to have more than one version of Perl. My approach, therefore, would be along the lines of identifying a real operational need for a single application that needs a later version. If it ain't broke, don't fix it. If you have the operational need, then try to persuade them to allow the parallel installation of a later version to be used for that application only. Once you have demonstrated that the two can coexist and that the additional functionality is useful, you can start playing a recording of "wouldn't it be nice to standardise on a single version".

    But I repeat for emphasis two points: don't change the system Perl and don't fix something that's working.

    Regards,

    John Davies

    Update based on chromatic's reply: you can point out that, as 5.8 is deprecated, you will have to upgrade if you upgrade the OS to a later version, so it would be helpful to start finding out what problems exist in good time.

Re: Arguments for upgrading from Perl 5.8
by chromatic (Archbishop) on Nov 17, 2011 at 19:21 UTC

    Perl 5.8 has been unsupported for a while now, so if you find a bug in Perl 5 itself, you're going to have to fix it yourself. (Canonical probably isn't going to support it for you.)

    If you find a bug in one of your CPAN modules, you may or may not get support from the author for Perl 5.8. That depends on the author. (I don't support 5.8. Canonical probably isn't going to support it for you.)

    If you need working Unicode, 5.12 is really the earliest version of Perl 5 that has anything close to complete support. 5.14 is your best option.

    (Perl 5.12 is a bit faster than 5.10 and uses a little less memory, and 5.14 continues that trend.)


    Improve your skills with Modern Perl: the free book.

      Unicode support is very important to us since we process international text.

      I thought that Unicode was added in Perl 5.8. I'm curious as to how much better the Unicode support is in Perl 5.12 vs. Perl 5.10 vs. Perl 5.8.

      Thanks

        Only as of 5.14 are most of the builtin operations fully aware of Unicode; too many of them default to assuming the semantics of whatever the local character set is. unicode mentions this as "The Unicode Bug". Perl 5.12 fixed some of that, but only as of Perl 5.14 can you use use feature 'unicode_strings'; to get Perl to do the right thing.

        I haven't encountered huge problems in my work, but most of what I do uses nothing more exotic than Latin-1 and UTF-8, so I've been fortunate. Then again, everything I care about runs on Perl 5.14.1 (and soon Perl 5.14.2).


        Improve your skills with Modern Perl: the free book.

Re: Arguements for upgrading from Perl 5.8
by ikegami (Pope) on Nov 17, 2011 at 21:05 UTC

    I would really like to get the production machine moved to 5.10

    There are arguments for and against upgrading, but upgrading to software that's been end-of-lifed? I think that's a waste of time.

      Thanks for pointing that out ikegami, I wasn't aware that Perl 5.10 had been end-of-lifed.

      The reason I was thinking of Perl 5.10 was because that's the version that the latest Ubuntu LTS (10.4/Lucid) supports. Upgrading to a non-LTS version of Ubuntu means you only get support for a year and then have to upgrade again.

      Installing a local version of Perl separate from the Ubuntu repos is possible but not ideal.

        Upgrading to a non-LTS version of Ubuntu means you only get support for a year and then have to upgrade again.

        It just goes to show that using the distro's Perl places the choice of whether to upgrade or not out of your control. Sometimes, it's ok to be at the mercy of another company. Sometimes it's not. I can't answer that for you, but asking the question you are asking seems to indicate it's not.

        (Previous paragraph rewritten based on better understanding of quoted line.)

        Installing a local version of Perl separate from the Ubuntu repos is possible but not ideal.

        I think it's *much* better than the alternative. Three major advantages:

        • You don't have to run the same OS and OS version on every machine.
        • You can upgrade or not upgrade Perl independently of other upgrades to the machine.
        • You can test your application with a new installation of Perl while still having the old version installed. This allows you to make sure the machine is setup correctly risk-free, and it allows switching to the new Perl without any downtime.
Re: Arguements for upgrading from Perl 5.8
by JavaFan (Canon) on Nov 17, 2011 at 21:29 UTC
    What arguments could be used to justify an upgrade like this?
    I'd say, that if you, with knowledge of the needs of your company cannot answer that question, and have to ask a bunch of nerds without any idea of your business processes for justification, I'd say, you don't have any justification what so ever.

    Let me ask you, is upgrading to 5.10 (or 5.12 or 5.14) going to make your company more money (now and in the near future)? Don't forget to deduct the cost of the upgrade itself from any increase in revenue (or to add it to whatever savings an upgrade is giving you). If you cannot make a business case for it - don't upgrade. Or at least, don't do it now. Don't forget that your customers don't give a flying fuck whether your server runs perl 5.8, perl 5.10, perl 5.14, perl 6, ruby, python or something else. They just want whatever service or produce you're providing.

Re: Arguements for upgrading from Perl 5.8
by furry_marmot (Pilgrim) on Nov 17, 2011 at 21:48 UTC

    Sorry, but another vote for leaving it alone. If you're stuck on particular bugs, or if modules you use regularly have been upgraded and only work on later versions of Perl, that could give you the basis of your case for upgrading. But why 5.10??? The fact that you're talking about only getting the features in 5.10 suggests it's more of a "latest and greatest" kind of thing than any real business need. Perl 5.10.1 fixed a bunch of bugs in 5.10, and there are two major releases after that, with 5.16 not too terribly far away; so upgrading to 5.10 is just pointless.

    Still, if you just want to install a more recent perl, perhaps pointing out to your bosses that you're three major releases behind, you could also replicate CPAN on a local machine, and install current modules from there.

    But if all you want is say and given/when, you can replicate something quite close to those quite easily.

    --marmot

      The project is still being developed with me as the primary coder. My sense was that a new version of Perl would make me more productive and allow for a cleaner code base. I use modules by switch and say but there's no way to replicate other features such as '//='

      Of course, it's hard that quantify benefits like that. It's true that there's a one time cost to upgrading and that it would be possible to continue development with 5.8. On the other hand, just because a technology works doesn't mean it's optimal to continue using it. For example, Perl 4 could also be used for a project but Perl 5 clearly results in better productivity and higher quality code.

        If Unicode is a vital part of your project, specifying just "5.8" is not enough. I really cannot think of any application running code to deal with Unicode reliable on anything older than 5.8.4. In the (way too) long development life-cycle of 5.8.x Unicode support has hugely improved, so 5.8.8 will do MUCH better than 5.8.5. This trend set on in subsequent releases, and if Unicode is core business, moving towards 5.14.2 is a very healthy move. The jump is big though, and you will have to test everything very carefully.

        Using modules like Switch is a VERY bad idea in 5.8, especially when you plan to use defined-or in 5.10 and on. They do not combine and scripts will crash in unexpected ways. I always used perl 5.8.x with defined-or (//=) built-in ( yes, there is a patch available to make 5.8.x have // natively), so I hit that problem in early stages and decided to never use Switch ever again.

        Then came given/when, but it was based on smart-match, which has its own snakepit of unpredictable issues.

        Summarizing: a move from earlier 5.8 to later 5.8 is warranted by 64bit issues and a little bit of Unicode. A move to 5.10 is warranted by the defined-or being available by default and much better CPAN support: authors are dropping 5.6 by the masses and 5.8 will be dropped rather sooner than later. A move towards 5.12 or 5.14 is good if your Unicode processes are core business.


        Enjoy, Have FUN! H.Merijn
Re: Arguements for upgrading from Perl 5.8
by scorpio17 (Monsignor) on Nov 17, 2011 at 22:16 UTC
    Ubuntu 8.4 is no longer supported, either. I'd recommend upgrading to 10.04 LTS, which has Perl 5.10. Do this on a spare machine and see what, if anything, breaks.

      8.04 has server-class support until 2013.

      Even so, 5.10 is at its end of life too, so that's just delaying the inevitable.


      Improve your skills with Modern Perl: the free book.

        that's just delaying the inevitable

        But still, it's better than doing nothing. The next step would be to update the staging machine to the next LTS version, that hopefully has a newer perl. As a nice side effect, dlarochelle gets a chance to plan for continuous updates, and to test that plan.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: Arguements for upgrading from Perl 5.8
by sundialsvc4 (Abbot) on Nov 18, 2011 at 01:13 UTC

    Step into your management’s shoes and attempt to construct a business cost/benefit/risk analysis.   This is a production system with over two hundred CPAN modules ... and exactly where is the overwhelming business justification to change anything?

    I’m not saying that such a justification does not exist.

      ... and exactly where is the overwhelming business justification to change anything?

      In my business, where I am the technical manager, it's very simple. We don't run unsupported versions of Perl. While we may never run into bugs in Perl that could block our business, the fact that we're never getting those bugs fixed in unsupported versions is a bigger risk than that of upgrading frequently.

      A blocker bug means we lose real dollars. Testing an upgrade means launching an automated process and, almost always, getting the green light to proceed.

      Certainly upgrading regularly has an upgrade tax, but in the case of Perl it's reasonably easy to test upgrades and deploy upgrades, and that tax is much, much less with a good process for upgrading regularly. Perl 5's predictable release and upgrade schedule, as well as the entire CPAN infrastructure, is immensely helpful.


      Improve your skills with Modern Perl: the free book.

        /me nods...

        And in my business, ditto, so do we.   After carefully weighing, for example, the potential impact to any system-management tools being used by a distro vendor. We often compile Perl from source, just the way we like it, and put it into /usr/local/bin.   We also deploy CPAN libraries into a /usr/local subdirectory and make sure that we are referencing it at the exclusion of any system-provided modules.   You have to maintain absolute jurisdiction over the entire environment that affects whatever you deploy, and every part of it has to be precisely reproducible in the test cases.   So, there is always a business necessity to be weighed, and a deployment and testing and maintenance plan to be drawn-up and so on.   It can be “quite the bit o’ busy-work,” actually...

        It’s really rather annoying, for lack of a better word, that the language-system versions used by many distros are routinely so old.   But they all build up quite an assortment of system management tools which are dependent on that stuff, and I know they don’t have too much of an alternative either.

      However, an upgrade at some point is inevitable. The next Ubuntu server won't come with 5.8

      A separate install of a latest perl for one application allows you to do get things done at your own pace rather than when you upgrade the server. You can test your other applications one a time and be ready for the Ubuntu upgrade when it occurs.

Re: Arguements for upgrading from Perl 5.8
by admiral_grinder (Pilgrim) on Nov 18, 2011 at 14:38 UTC

    The question is are you able to do it and prove it to your boss that there is low risk? Do you have good automated tests? At least enough do demonstrate that 'it mostly likely will work, until users do something screwy'?

    My argument would be that as you expand the code you are going to want to use some new feature or bug fix and then that is going to cascade into dependency hell trying to get it supported.

    200 CPAN modules shouldn't be an issue unless you don't archive them and have a list of supported versions. I had an app that by the end of 3 days required me finding and installing 125 modules. That led me to come up with an XML file that would describe what modules I wanted, what the dependencies where and other things I needed to consider. I then took a few days to create a script that would read it, build, test, and install modules. Only took about 2 weeks of active use to work out all the bugs in it, but I use it all the time now with no issues (unless a module has a screwy install).

    I believe it would be better in Ubuntu to setup a new Perl instead of one of 200 CPAN modules borking up the system. While the CPAN shell is nice about resolving dependencies, you don't really realize how big some of those trees are (XML::Compare needs at least 18 modules). Alternative is to make a new location for CPAN modules in your app and make sure your privileges are read only on your system perl.

Re: Arguements for upgrading from Perl 5.8
by Anonymous Monk on Nov 18, 2011 at 17:31 UTC
    Which versions of perl are available in your OS vendor's repositories is all about running the scripts that you are paying support for.

    Instead of a version that is in the repositories, you probably want a home built copy of perl in some place like /usr/local/bin . This way your scripts can call it for the latest in Unicode/RegEx/Feature support and the vendor's perl scripts can run off the vendor's version.

    Building Perl on Unix/Linux is easy, and since you won't be using the system's perl for custom coding, you won't need to update CPAN modules against the 5.8 lib/ directories. In fact keeping your modules up to date against a current version of perl will probably be (only slightly) less effort.

Re: Arguements for upgrading from Perl 5.8
by talexb (Canon) on Nov 18, 2011 at 18:01 UTC

    I'll join in with the dreaded phrase 'technical debt'; the longer you put this off, the greater the risk. One of the rules of business is that you prefer to minimize risk. So get a new production server, install the latest OS on it (which will include the new Perl), update everyting, and see how it behaves.

    At some point, like tearing off a band-aid, you have to get started. You're already living on borrowed time with your existing server. There's a greater risk in doing nothing, rather than getting started.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Reaped: Re: Arguements for upgrading from Perl 5.8
by NodeReaper (Curate) on Nov 21, 2011 at 13:03 UTC
Re: Arguements for upgrading from Perl 5.8
by tsee (Curate) on Nov 22, 2011 at 20:55 UTC

    Enormously good reason to upgrade: Exceptions are much less broken.

    Quick explanation: During stack unwinding when an exception was thrown, your exception might be clobbered from $@ (A simple eval somewhere in code called from DESTROY of an object can do the trick). That no longer happens with 5.14. This kind of error is among the worst to debug I've seen.

Re: Arguements for upgrading from Perl 5.8
by Brutha (Friar) on Nov 24, 2011 at 16:14 UTC

    I would like to add an argument not to upgrade too fast. I am testing a 5.14 installation and found some not working modules:

    UNIVERSAL->import is deprecated and will be removed in a future perl a +t C:/Perl.514/site/lib/POE/Component/Client/TCPMulti.pm line 30 BEGIN failed--compilation aborted at C:/Perl.514/site/lib/POE/Componen +t/Client/TCPMulti.pm line 30.

    So do a complete testing and allow You some time to checkout all your scripts and apps as this might save you a lot of work later. It was already said above, never change a running system without need. Unsupported software is a big need - as chromatic explained - but update carefully

    And it came to pass that in time the Great God Om spake unto Brutha, the Chosen One: "Psst!"
    (Terry Pratchett, Small Gods)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://938667]
Approved by davies
Front-paged by MidLifeXis
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (14)
As of 2014-10-23 19:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (128 votes), past polls