|Perl: the Markov chain saw|
Re: Maintaining an Enterprise Perl Distributionby perlfan (Curate)
|on Mar 24, 2005 at 19:54 UTC||Need Help??|
* How often do you upgrade your Perl? What version do you run in your production environments?
I move up whenever the need behooves me. Most machines I work on are still at 5.6.1. More importantly, I try to do things in a way that minimizes any breakage that might occur. This means, usually, that I try to use features available only in the lowest common denominator, which for me is 5.6.1.
* How often do you upgrade your modules? Do you try to always stay with the latest version?
I am one of those who tries to stick as close to core as possible, so when I do need a module, I install it. I usually do not have everything and the kitchen sink installed. Every once in a while, I check out the latest versions of the modules I use, and only upgrade if there is a compelling reason to do so.
* How do you deploy your Perl distributions? (install modules on each machine, autodeploy somehow, etc.)
Modules, usually. http://par.perl.org is also a good thing to look into if you are depolying apps to a customer.
* Do you include external packages (like external C libraries) in your distribution system?
http://par.perl.org will let you do this, but I again am one of those who tries to use pure Perl with as few dependencies as possible.
* 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)?
No, but I use the modules that install - i.e., I only install modules when I need them.
* How do you test your applications after a module or Perl upgrade?
I don't really - unless it *breaks*.
* We'll upgrade to the latest stable, then stay within two releases of stable.
As far as your plan goes, it is difficult to say what you should do. Do what your obligation to the customer demands. The best thing for you to do, in my opinion, is to keep current with info on the modules that you use, upgrade only if there is a compelling reason to do so, and test its effects in test environment before you blindly deploy your app that relies on untested (to you) third party software.