Is this Canary::Stability rant a legitimate concern?

Question

I was installing new CPAN modules today, and it turns out that the JSON::XS module displays its own warning/rant about using it with Perls over 5.22. It seems the author got fed up with backward-incompatible changes allegedly introduced into Perl after that point, and decided to make a module dedicated to warning people about potential incompatibility, warning against Perl over 5.22, and promoting a separate branch of Perl dedicated to stability.

As a humble average user, I am not sure how alarmed I should be. For example: Is it just this one user/module complaining, or is it bigger than that? Are there known serious issues with Perl backward-compatibility after 5.22?

I guess this is a somewhat subjective question, but by doing this the author has made it everybody's problem (alternatively: has made the stability branch everybody's solution, depending on whose side you take). And since I need to choose a Perl version for a big porting project I'm working on, it's a pretty important question to me.

Here is the warning:

Canary::Stability COMPATIBILITY AND SUPPORT CHECK

Hi!

I do my best to provide predictable and reliable software.

However, in recent releases, P5P (who maintain perl) have been introducing regressions that are sometimes subtle and at other times catastrophic, often for personal preferences with little or no concern for existing code, most notably CPAN.

For this reason, it has become very hard for me to maintain the level of reliability and support I have committed myself to in the past, at least with some perl versions: I simply can't keep up working around new bugs or gratituous incompatibilities, and in turn you might suffer from unanticipated problems.

Therefore I have introduced a support and compatibility check, the results of which follow below, together with a FAQ and some recommendations.

This check is just to let you know that there might be a risk, so you can make judgement calls on how to proceed - it will not keep the module from installing or working.

The stability canary says: (nothing, it was driven away by harsh weather)

It seems you are running perl version 5.026000, likely the "official" or "standard" version. While there is nothing wrong with doing that, standard perl versions 5.022 and up are not supported by JSON::XS. While this might be fatal, it might also be all right - if you run into problems, you might want to downgrade your perl or switch to the stability branch.

If everything works fine, you can ignore this message.

Stability canary mini-FAQ:

Do I need to do anything? With luck, no. While some distributions are known to fail already, most should probably work. This message is here to alert you that your perl is not supported by JSON::XS, and if things go wrong, you either need to downgrade, or sidegrade to the stability variant of your perl version, or simply live with the consequences.

What is this canary thing? It's purpose is to check support status of JSON::XS with respect to your perl version.

What is this "stability branch"? It's a branch or fork of the official perl, by schmorp, to improve stability and compatibility with existing modules.

How can I skip this prompt on automated installs? Set PERL_CANARY_STABILITY_NOPROMPT=1 in your environment. More info is in the Canary::Stability manpage.

Long version of this FAQ: http://stableperl.schmorp.de/faq.html Stability Branch homepage: http://stableperl.schmorp.de/

Answer 1

p5p, the informal team that maintains Perl, takes backwards compatibility very seriously.^[1] They have a formal policy concerning this in perlpolicy.

Let's put Canary::Stability into context.

The author in question has a number of modules that use undocumented Perl internals that are subject to change. Using these internals is necessary to achieve what the modules do, but one has to realize these are subject to breaking.

And yes, p5p have changed some internals in ways that broke this author's modules, but p5p checks what modules on CPAN their changes will affect, and p5p provide fixes for affected modules far ahead of releasing a new version of Perl.^[2]

The author in question is extremely difficult to deal with, and would rather spend time taking stands rather than maintaining his modules or working with p5p towards exposing the internals to which he needs access.

For example, difficulties in dealing with him has lead people to fork JSON::XS into Cpanel::JSON::XS. One of the problems is that he'd rather rant against threads than make JSON::XS thread-safe.

For example, CPAN provides a means of specifying where bug reports should be submitted. The author would rather that you email him directly instead of using the default means of reporting a bug (the CPAN-provided bug tracker). The lack of visibility of using email instead of a public bug tracker is a problem in and of itself, but he compounds it by refusing to indicate in his distributions how he wants to be contacted. If you dare submit a bug through the CPAN bug tracker (which he de facto indicated you should use), he emails you a prepared rant longer than the one you posted.

---

1. There have been hickups, but they learn from their mistakes. For example, this is how experimental features came to be.

2. There are "smokers" that continually run the test suite of every module on CPAN against "blead", the development branch of Perl. Differences in test results between runs are manually examined to see if they were caused by a change in Perl. If so, a "Blead Breaks CPAN" (BBC) ticket is opened. Maybe it was a bug that was introduced. Maybe the module was doing something buggy. Maybe it is a backwards-incompatible change that needs to be reverted (and maybe a deprecation will be introduced). Or maybe it is a backwards-incompatible change to internals that needs to move forward, in which case they will help the broken modules.

   Modules in the DarkPAN (i.e. not on CPAN) obviously don't get the same level of support from these smokers as the modules on CPAN do. But you are free to test your modules against the dev branch or dev release if you are particularly concerned.