Re: Maintaining an Enterprise Perl Distribution

The very first thing you need to figure out is

Do I need to upgrade at all?

Upgrading is a change. It's a massive change, actually. Is the cost of testing this change worth the benefits? What are the benefits? Do you have a backout plan if something breaks?

Personally, I would upgrade on a case-by-case basis. If version 2.44 of the Floopy module works for you, why does it matter if the latest version is 4.55? If you never hit a bug, then you don't need the bugfixes. Plus, bugfixes might introduce bugs you're not aware of. If you need a feature in 4.55, then upgrade to it.

Furthermore, the issue isn't bugs within a given module - it's bugs between modules. Integration testing is expensive! And, testing doesn't prove the abscence of bugs - it simply shows you haven't found any yet.

Thinks for a second . . .

The biggest problem I have with your plan is that you're changing too many things at one time. Change one item, then see what happens. If nothing breaks, bake it in for a month. Then, change another thing and see what happens. Lather, rinse, repeat.

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.

Comment on Re: Maintaining an Enterprise Perl Distribution

Replies are listed 'Best First'.
Re^2: Maintaining an Enterprise Perl Distribution by cbrandtbuffalo (Deacon) on Mar 24, 2005 at 20:30 UTC
That's a good point, and one I'm laboring over. Things are working OK now, but there are a few 'little' things wrong with some of our modules that are fixed in newer releases. Some of these modules, like Class::DBI, have many dependencies, so an upgrade involves updating other modules. The problem with standing pat is it's hard to get help when things are broken. When we have an error, the first thing the Monks or people on a list ask is "what are you running?" Too often in the recent past, we have this strange mix of modules and versions. So the answer is "upgrade and see if that fixes it." And this is a completely legitimate answer since it is just too hard to track interdependencies across strange combinations of module versions. So I guess I'm hoping we can better troubleshoot things by staying more current. But maybe this isn't the case? Another solution might be to just do spot upgrades when we have to because we run across something. The problem here is exactly what you mentioned: testing is hard and costly. If we just did it 'as needed', it would also be un-planned. We have a lot of perl code running, so it's difficult to arrange for ad hoc testing of everything. If we had an upgrade schedule, at least we could plan the testing.	[reply]
Re^2: Maintaining an Enterprise Perl Distribution by seanbo (Chaplain) on Mar 27, 2005 at 15:02 UTC
I agree wholeheartly with many things you said here. Change isn't always a good thing. I strongly recommend using a test server to see what breaks when you upgrade anything before you just deploy it all over, ESPECIALLY if you are highly dependant on it. In my personal experience as a system administrator, unless mandated by the need for a feature, repair of a bug or a security update, an upgrade is an unneccesary act and often times a very dangerous one. When I was new to system administration, I thought that it was important to stay "within two releases" etc as is mentioned in the initial post. I quickly realized (after a horrible problem surfaced) that my logic may have been a bit flawed. I adopted a new philosophy...upgrade when there is some need to do so, otherwise, leave it alone. dragonchild is right about changing too many things at once as well. If something does break (and trust me...it WILL), it will be far more difficult to find and correct the problem if you changed multiple things. If you must upgrade many things, do it in reasonable phases where you can simplify any troubleshooting. You will thank yourself later. Just my $0.02. perl -e 'print reverse qw/o b n a e s/;'	[reply]