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!