cbrandtbuffalo has asked for the wisdom of the Perl Monks concerning the following question:
I'm looking for some wisdom from the Monks on how to keep our distribution up to date after we upgrade everything.
Some specific questions:
- How often do you upgrade your Perl? What version do you run in your production environments?
- How often do you upgrade your modules? Do you try to always stay with the latest version?
- How do you deploy your Perl distributions? (install modules on each machine, autodeploy somehow, etc.)
- Do you include external packages (like external C libraries) in your distribution system?
- Do you track what modules are actually being used? Do you remove modules that no one is using anymore (one less module to monitor and stay on top of)?
- How do you test your applications after a module or Perl upgrade?
My current proposals for our system are something like this:
- We'll upgrade to the latest stable, then stay within two releases of stable.
- We'll run upgrades of all modules every six months. We won't upgrade to a version that is less than a month old (I've seen too many releases followed by quick bug-fix releases.). We will have provision for interrim upgrades of a module if necessary. We'll use the CPAN module with some scripts to manage this process.
- We currently use our Perforce version control system to manage and deploy our distribution using scripts. This works well, but we don't currently track external dependencies (for example, expat for the XML modules).
- For testing, we have all developers run their tests, including WWW::Mechanize tests for our web apps. This can be a bit time-consuming, so that's why I'm going to suggest only twice per year.
I'm also interested in any other advice on maintaining a reasonably up-to-date Perl distribution in an enterprise environment.