I want to advise on this topic. Overall, module upgrades are beneficial, additional to the usual improvements to code and API, they include bug, performance and security fixes (not every vulnerability in a CPAN distribution is assigned a CVE). Living with CPAN means to always be on the bleeding edge because the CPAN clients install the newest version of a module (unless it is marked as a trial release), the same is true for the resolved dependencies which are typical plentiful, and the older version is then just gone.
This is usually a recipe for disaster, but Perl programmers write their software in a CPAN-ready fashion to take advantage of the existing toolchain and include tests which are run against an upgraded dependency⁰, so this is nicely mitigated. However, if the sysadmins upgrade right on release they would torpedo this; the authors need a respite for testing. Toolserver authors, on average, are not good Perl programmers¹, and lack these basic community best practices pointed out above, thus I propose that a moderate approach should be taken if you decide that the advantages of a steady upgrade cycle outweigh the risks of breakage through introduced incompatibilities. This is similar to what you have been already doing for other toolserver software: ⒈ Determine the cycle length after which a collective update is run; I'd judge 3 months to be on the very conservative side. ⒉ Collect the update candidates with `perl -MCPAN -e'CPAN::Shell->r'` or App::cpanoutdated. ⒊ Make an announcement and include permalinks to the changelogs, e.g. <http://search.cpan.org/dist/Crypt-SSLeay/Changes> goes to the appropriate version. ⒋ Wait out the time-frame from the announcement. ⒌ Upgrade the candidates except those who had another stable release during the wait. ⁰ http://www.modernperlbooks.com/mt/2009/02/the-darkpan-dependency-management- and-support-problem.html ¹ If you are, this is your chance to unlurk, say hi!
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Toolserver-l mailing list ([email protected]) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
