I've had systems running versions of perl that were years out of date. This has only been an issue in two types of situations --
- one of the developers (okay, me), needed some functionality that was only in a new version.
- (I think this happened once in 9 years.)
- Solution: Install the new version of perl in an alternate location. (see the discussion in Solaris, Perl 5.8 and use 5.005) Developers who want to use this new version would need to explicitly specify this new version.
- Problem: may not work for mod_perl; this is a pain if you're just doing it for a module, so you don't muck with the original one in place
- Problems moving scripts between systems.
- Okay, this one has stung me a few of times. Sometimes it's just a different perl location in the shebang line, but there have been a couple of times when my code didn't work with more recent versions of the module. (I remember a bad time once with Net::LDAP, but I just went and backed down the version so the systems matched, and I didn't have to change my code, as it was being moved because of a system failure, and I didn't have time to spend on it). Personally, I just look at which modules are giving problems, and fix those issues, rather than going for a complete sync across the board.
So, basically, to answer your specific questions:
- I don't, if I can avoid it. The installed default, and possibly whatever was current at the system was configured.
- When I need some new functionality that the new module provides ('functionality' to include bug fixes). No.
- Install modules as needed, on a per machine basis.
- nope, as I do it by hand.
- System documentation. No.
- I try not to upgrade, but if I have to, I run whatever tests the development teams have given me. Which is to say, I don't run any tests. But I then leave it running on the development servers until management signs off on it being tested, and then move it to production. (If something breaks, I've got record of someone signing off in the change management system, showing they didn't test their stuff).
Yeah, I've probably read too much BOFH over the years, but well, I've been a developer, and a sysadmin ... if it's important, you write tests for it. If management drives a schedule that results in nothing being thoroughly tested, I make sure they sign off the system before upgrades.
Note: I've since changed jobs, to where I only have to deal with one production system (that's in my control... we have four replicas, distributed geographically, on hetereogeneous versions and hardware, but I don't manage them), and I get control of my part of the production schedule, within reason, so I don't have nearly so many issues anymore. It's much better than trying to deal with ~30 web, ldap and mail servers and idiot management.
