Re: Maintaining an Enterprise Perl Distribution

[dragonchild]

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.

[cbrandtbuffalo]

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.

[seanbo]

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.