Credit: https://medium.com/xebia-engineering/branching-and-release-strategies-119e60241345

This is part III of my blog on versions. Last time we discussed the question of what version of perl to use for development. Conclusion: In most cases, the choice will be made for you, especially in maintenance and legacy migration situations. If you have the luxury and ability to use a more version of perl, use it. Let’s continue:

• [x] What version of perl should I be using for development?
• [ ] If I publish a CPAN module, what version(s) of perl should I support?
• [ ] What version of a dependency do I really need in my module?
• [ ] What should I do if I receive errors in the CPAN Testers Report?
• [ ] Should I include core modules as dependencies? (the answer is not as obvious as you might think)

If I publish a CPAN module, what version(s) of perl should I support?

For me, this has become more than just an academic question. Several years I ago I petitioned the Pause administrators to allow me to adopt Amazon::S3. It had been a long time since the module was updated and it needed a little TLC to support new features and fix some deficiencies. The adoption process took a lot longer than I had imagined. Between the time I requested co-maintainer rights and the time it was actually granted the urgency and desire to adopt the module waned. Recently the need to update this module has re-appeared so I began making some much needed improvements. My first release to CPAN of the updated module was 0.49 and thus began my introduction to CPAN Testers Reports.

My first release only passed (accidentally) on a few versions but seemed to passs on at least 1 version of all operating systems tested. The failures were all due to missing dependencies that I had failed to identify in Makefile.PL. Thus a new release (0.50) was required - somehow I made the same mistake, however as you can see from the report, a new max version (5.37.1) emerges due to one of the testers adding that version to its list of perl versions to test. I say the tests that passed, passed accidentally, because I’m guessing that those testers had (for some reason) the necessary modules installed in their environment.

That’s an important point to consider - all testing environments are not created equally. By looking at the reports, we can conclude empircally that there must be something different about these environments if the module fails on one tester’s version of perl 5.37.1 and another passes? Take this report for example:

Note the failed tester and the OS version. The version of the OS is different in the failing tester’s report…however the failure was due to XML::Simple not being installed because it was missing from the list of dependencies in Makefile.PL. So why did the other’s pass? The conclusion must be that XML::Simple was somehow present in those environments otherwise they would would failed there as well.

Some other oddities of the CPAN Testers Reports is what versions of perl are used for testing the module. After releasing 0.50 I noticed that version 5.8.9 of perl suddenly showed up in the testers report. Hmmm…should I try to support that version? Is there a reason it shouldn’t pass on 5.8.9? What versions of perl did the original author’s 0.45 version support? Well, as it turns out when that module was tested in 2012, it support 5.6.2! Should I support 5.6.2? Would it actually be possible to support perl 5.6.2?

The answer as it turns out is no. Version 0.45 would probably not pass version 5.14.0 due to the versions of perl that are required by the module’s dependencies.

Version 0.45 specifies that any version of LWP::UserAgent::Determined will do, which in term will require any version of LWP.

As I futilely attempted to see what the minimum version of perl my adopted module could support I attempted to build LWP on version 5.10.0 of perl. Unfortunately, LWP would not build on 5.10.0 (actuall it was the module HTTP::HeadParser that is part of libwww-perl that failed unit tests) so I dutifully filed an issue assuming that the authors of LWP would want to know that the module does not build on 5.10.0.

The response to my report was suprisingly - let’s bump the required version of perl to 5.14. So, while LWP successfully builds on 5.14.0, LWP::UserAgent::Determined does not.

After a lot of useless traversing down rabbit holes I was able to determine that installing an older version of LWP would, in fact succeed in building LWP::UserAgent::Determined. The rub here however is that other modules like XML::Simple require yet other modules that specifed that any version of LWP would do. If the dependency that required any version of LWP is installed prior to installing a specific older version of LWP listed in my manifest, well, now we’ve installed an incompatible version of LWP because specifying any version of LWP will bring in the latest version.

Now, if cpanm had done the right thing and installed specific versions of modules specified in the dependency list first, then the older version of LWP would have satisfied the requirement. This is not to say that cpanm did the wrong thing…it got the list of direct dependencies from the distribution and started installing them.

To be fair, the versions of perl I have been testing against are old. CPAN authors should not be bound to supporting older versions of perl at the expense of modernizing or enhancing their modules. The point is to simply illustrate the difficulty in releasing a CPAN module that does support older versions of perl.

So should I then conclude that I need to bump the minimum version of perl that Amazon::S3 will support to something like 5.16.3? If I still want to support older versions of perl would it even be possible to find the versions of dependent modules that do not break my build? Does that even make any sense when modules are sometimes updated to fix bugs?

As it happens, I did manage to get a working build for perl 5.10.0 and 5.14.0. Of course, it was a forensics exercise and not very satisfying to be truthful.

By installing version 6.13 of LWP and version 2.14 of HTML::HeadParser I managed to somehow get Amazon::S3 to build and complete all tests successfully.

The guidelines to support older versions of perl seem to be:

1. Only use features from the minimum version of perl you plan to support
2. Verify that any dependent modules also conform to #1 and can be built on the minimum version of perl you plan to support
3. Verify that your unit tests are comprehensive enough so that if there are bugs in older dependent modules, they do not effect your code
4. Be specific about the version of dependent modules required by your module

more next time…