• Near-transparent handling of Unicode (5.8)
• A threading model worth having (5.8)
• Granular warnings (5.6)
• A module from CPAN that only works on version 123

Additionally, there have been hundreds of security and bug fixes since 5.005_00 was released, all of which are in 5.8.6 (the latest version thus far).

A major reason --NOT-- to upgrade is that you have to reinstall EVERY SINGLE module, and all their dependencies, and all their dependencies, etc. The 5.8 series is not binary compatiable with pre-5.8 installs. This reason alone is sometimes justification enough to avoid an upgrade.

Additionally, if it ain't broke, why you trying to fix it? It's not like 5.005 is unstable through aging or has gained cruft in the time since it was released ...

Now, to answer your specific questions.

1. You can't upgrade to 5.8 without an upgrade of the OS.

   This is flat wrong. I have run 5.8 on operating systems that were released before Perl5 was even a twinkling in Larry's eye. The easiest way to disprove it is to build your own personal copy of Perl. To do this, you download stable.tar.gz from http://www.cpan.org and use ./configure PREFIX=~ when you build it. The build will take roughly a workday and hammer the server, so I suggest you kick this off overnight after you've done the configure.

2. Company policy is to have only one version of the perl binary

   Company policy is unchangeable, at least from the level it seems like you are. Multiple Perl installations are easy - just call them different things or put them in different places. They will install their libraries in directory structures that include their version number, so there's no clobbering.

3. Existing apps will break

   Yes and no. You will have to reinstall the entire module base, but that won't break existing apps. Unless, of course, you install incompatible versions of certain modules, like Class::MethodMaker whose API changed between v1 and v2. Or, if you depended on a bug in a prior version of a module and that bug has gone away.

   The easiest way to test if this will happen is to install 5.8.6 in your home directory and try your applications with it. If they work, that will give management a bunch of warm fuzzies. If they break horribly, that allows you to not look stupid when the migration is approved and you can't make it happen. (That's because you were sick on the day of the meeting and shut your hole.)

Hello dragonchild , and thanks for your answer .

Additionally, if it ain't broke, why you trying to fix it?

A new app will be developped on this server . We don't want to start developpement with 5.0 .

You will have to reinstall the entire module base,

Is it not possible to have a second perl binary, with a different she bang and a different default @INC ? If i manage to have two perl binary (you never know) then i also want to have two different module librairies. This way existing application does not have to migrate, new application is 5.8 .

In the case they insist to have only one binary, i understant we should check code and tree for modules and reinstall them .
This meeting is a first, no one's in charge of nothing, and i will certainly listen to what the conservatives have to say. But if it starts with "we need to re-install solaris", then i don't know .

Yes it is entirely possible to have a different Perl installation - you simply use a different PREFIX when you run Configure. IMO this is preferable to replacing an existing perl if you don't want to have to test and possibly fix a whole bunch of existing code. And it is definitely what you want to do if you have a preinstalled Perl that came with your OS (though I don't think Solaris 6 did.)

/J\

I'm willing to go out on a limb and say unequivocally "You will never need to reinstall Solaris to install Perl 5.x.x". If they persist, ask them for their proof and bring it back to us. I feel very comfortable that we can provide answers that will satisfy.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

As gellyfish said, you can have multiple perls installed simultaneously:

$ perl -v

This is perl, v5.8.0 built for i386-linux-thread-multi
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2002, Larry Wall

Perl may be copied only under the terms of either the Artistic License
+ or the
GNU General Public License, which may be found in the Perl 5 source ki
+t.

Complete documentation for Perl, including FAQ lists, should be found 
+on
this system using `man perl' or `perldoc perl'.  If you have access to
+ the
Internet, point your browser at http://www.perl.com/, the Perl Home Pa
+ge.

$ perl5.8 -v

This is perl, v5.8.6 built for i686-linux

Copyright 1987-2004, Larry Wall

Perl may be copied only under the terms of either the Artistic License
+ or the
GNU General Public License, which may be found in the Perl 5 source ki
+t.

Complete documentation for Perl, including FAQ lists, should be found 
+on
this system using `man perl' or `perldoc perl'.  If you have access to
+ the
Internet, point your browser at http://www.perl.com/, the Perl Home Pa
+ge.

$ p58 # change environment
$ perl5.8.3 -v

This is perl, v5.8.3 built for i686-linux

Copyright 1987-2003, Larry Wall

Perl may be copied only under the terms of either the Artistic License
+ or the
GNU General Public License, which may be found in the Perl 5 source ki
+t.

Complete documentation for Perl, including FAQ lists, should be found 
+on
this system using `man perl' or `perldoc perl'.  If you have access to
+ the
Internet, point your browser at http://www.perl.com/, the Perl Home Pa
+ge.
[download]

Note - I have 5.8.4 and 5.8.5 installed as well. Except for 5.8.0, they inherit each others' modules, as well. 5.8.0 is what comes with RHEL3, which I leave as-is so that RHEL3 apps continue to work, while the rest were compiled into a new directory, /share/perl5, and are what I use for my own code. Before I upgraded to RHEL3, I had RH7.3, which had Perl 5.6, and I also had compiled 5.8.0, and 5.8.1.

As to "start developpement with 5.0" - that's not quite what you're doing. Between 5.005 and 5.6, Perl renamed its numbering scheme a bit. 5.005 in the old scheme is the same as 5.5 in the new scheme. Which is significantly newer than 5.0 ;-)

Update: After re-reading the output, I realised that I hadn't updated my perl5.8 symlink to the latest perl version. Corrected the output above.

I have the wonderful joy of having virtually the same issue at my company (using perl 5.005).

First, before you do anything, you have to justify why you want to upgrade. There are some reasons that are irrefutable. These are the "We want to use feature XYZ and it's only in version 5.x.x". Features like that would include:

• * Near-transparent handling of Unicode (5.8)
• * A threading model worth having (5.8)
• * Granular warnings (5.6)
• * A module from CPAN that only works on version 123

To this list you can add:
• the ability to use warnings without -w
• the ability to have our $var
• better handling of FOO->method;
  (broken in 5.005, must type FOO->method(); )
Since legacy code is mostly likely to break with such a new verison of perl, it is important to upgrade in a graceful way. The best way to do this is to install perl 5.8 in its own directory (your home dir perhaps, or /usr/local/bin), install all the CPAN modules you need, and migrate over one perl app at a time, testing as you go. Eventually, every app can point to perl 5.8 if the effort is made to port it, and those apps that are not ported to perl 5.8 can happily stay the way they are.

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

• IIRC The perl5.8 from http://sunfreeware.com installs in /usr/local, so all exising scripts that use /usr/bin/perl will continue working as is.
• Well you can install 5.8 over 5.005, but then you'd better be sure everything keeps working. I don't know if it will.
• Use 5.003 just specifies the minumum perl version, it does not alter the behaviour of the perl interpreter in perl 5. Perl6 might, though.

I don't know about Solaris 2.6, but I know that installing over top of the factory-installed perl in Solaris 8 (might've been Solaris 7) caused problems. (what they were, I don't particularly remember, as it's been a couple of years, and I learned from it, and never did it again).

So long as you install into /usr/local/bin, and do not replace the perl in /usr/bin, and do not set root's PATH with /usr/bin/local before /usr/bin, you'll be fine.

Users can then specify /usr/local/bin/perl or /usr/bin/perl as they want in their shebang lines. You will have to install whatever modules you may need all over again, and you should not have them use the same include paths (unless possibly if you have locally maintained pure perl libraries that you don't want to maintain in two places, you might share those, but for everything from CPAN, I'd install all over again).

I'm guessing though, if you're still running Solaris 2.6, you have other problems to worry about. (2GB file limit which could result in truncated backups, etc.) Depending on the exact situation, I might push the 'we need to upgrade', just to move off of Solaris 2.6, if that's what it would take to push the change.

Use 5.003 just specifies the minumum perl version, it does not alter the behaviour of the perl interpreter in perl 5.

Ah okay, it was too good to be true :|

2) I used to work at a company which had the policy of having documentation in Word format, while the development was being done in *nix platforms. Needless to say, their documentation was not as good as it should be... What I'm trying to say here is that just because something is company policy doesn't mean it's a good practice (but I'm not saying that only one single version of the perl binary is bad). Anyway, I can't see any problem with removing the older perl binary for the newer one; you shouldn't have any problem with that, but see the next point and do test the apps.

3) Can't help you with your questions, but regarding "Existing apps will break", how about including a testing part in the migration process?

1) Hmm, i think the perl was long ago compiled from source by someone who wasn't in the know. After that someone modified it in some strange ways, and it became a mess.

Now noone knows what's going on with it and if they want to make it clean by company standard they need to upgrade to solaris 8 : that's because Solaris 6 is being discontinued here so if you need to change something with the OS team it will have to be solaris 8 .

All this is mainly extrapollation from what i understand since it could also very well be political obfu or management war or whatever.

Also the dev server and the prod server are in different OS version ... Well , it just ain't nice .

I'll tell you more when i hear what they have to say 'Live' !

2) I have a feeling no one is really in charge of this ... Well there is a team in charge of things like version shipements, but for some reasons they also/mainly do mainframe things ?! I think their "one binary only" solution will not really solve problems because i haven't (yet ?) heard of a module management strategy. If everyone installs their own modules where they want it's bound to go chaotic !

3) As always it's a money thing. Also the code is quite old and seems awfull in some parts, so some ppl fear the results. On a "company scale" there's also a problem with the hudge number of servers and apps . For our own little app i guess we can go with two binary (if allowed), and/or a testing process ...

I'll tell you more when i hear what they have to say 'Live' !

Actually, this sounds a lot like a good beginning for a use Perl journal. Why don't you start one? (or post there, if you already have one) I'm pretty sure you'd also get a few responses there.

They're also missing out on the transition costs, which can be extremely substantial.

There are programs written in the late 70's that are running on hardware built in the early 70's that have been touched only to make them Y2K compliant (and some not even then). These programs do everything from keep the lights on to issue Treasury bonds to determine whether a nuclear-tipped missile should launch or not. I don't know about you, but I'd rather not "upgrade" a nuclear-weapons computer when it's been working just fine for 30+ years. But, maybe I'm just paranoid. Maybe, you can keep track of every change made between version 3.4 and version 27.8 and calculate how each will affect every one of the million lines of code written in a language that was deprecated when I was still in diapers.

And, maybe we just didn't need Detroit.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Every time i hear this argument im reminded of something. For a while we had a system that nobody wanted to touch. It was a scary hack done by someone in the far reaches of time. Well one day somebody was bold enough to decide to write a replacement system. They put it into play and did a paralel run. Much consternation was caused by the fact the outputs were different. The developer of the new system however was pretty surprised by this and as such began to do a detailed analysis of the code involved. Turned out the output of the two systems was different because the original system never worked properly in the first place. Well, needless to say the old system was soon replaced by the new system, and lo and behold, much money was earned and much rejoicing was done.

Not that it means your point is wrong, but there is another side to it. ;-)

---
demerphq

And another one - writing new app for a platform, and you can solve that by using PAR, create your app, and then compile it to elf file that you can safely run on your target solaris server.

This is a great way for packing apps without touching target system, I do that even if on target platform there already is modern perl available - this way the problem of installing myriad of required modules is solved in one place.

This will work as long as you're not using Gtk,