With the latest stable release of perl, v5.24.0, you could easily get trapped into using a problematic combination of math modules. Here is how, and what you should do to avoid trouble.

The Scenario

Perl has been supporting arbitrary precision integer, floating point, and rational number math with core modules for a long time. Math::BigInt and Math::BigFloat have been in the core since perl 5. Math::BigRat was first released with perl v5.8.0 in 2002. Currently these modules undergo heavy refactoring and also partial redesign, as can be seen in the changes files of the Math-BigInt and Math-BigRat distributions. Now here is the catch.

Math-BigInt-1.999718 of April 22, 2016, introduced changes to a couple of functions that were not particularly well documented before, but used by Math::BigRat, among others. Consequently, Math-BigRat-0.260803, also of April 22, 2016, was fixed to no longer depend on the old behaviour. These releases did not make it into the perl v5.24.0 release that came three weeks later, though.

The Path of Deception

Now as most of us know, these math modules can be made quite a bit faster by installing interfaces to heavy-duty math engines such as GMP or Pari. Modules providing the glue to these backends, such as Math::BigInt::GMP, are not in the perl core. You'll install them from CPAN. Not surprisingly they also have seen releases addressing the latest semantic changes.

The Tragedy

So you have perl v5.24.0 and want fast big rats rational arithmetic. A brand new Math-BigInt-GMP from CPAN will pull you a brand new Math-BigInt from CPAN, too, as the GMP glue depends on a later Math::BigInt version than you have. Your old version of Math::BigRat, however, will not be touched. And it will give you wrong results. Rational arithmetic simply will no longer work correctly on your platform.

The Escape Route

To fix this, you need to upgrade Math::BigRat from CPAN as well. Manually. This will not happen automatically as a consequence of your installing Math-BigInt-GMP.

The Morale

As a user, when you install something, your installer will likely take care of dependencies, but you in turn should look out for reverse dependencies. Metacpan.org can help you there somewhat. A tool running all the test suites of your installed modules after every change would be nicer, but I haven't come by one yet. If you upgrade everything you have once in a while you will at least run some tests, and you will eventually escape from situations like the big rat trap, while occasionally some prematurely released stuff may bite you.

As a module maintainer, if you don't like a particular functionality, you could make your users' lives easier by adding and advertising new methods rather than just replacing existing ones. If you feel really strong about getting rid of something you can stage a deprecation cycle. Research, discuss, announce, make the change configurable, allow some time to pass, swap defaults, wait some more, remove if you must.

I admit I didn't always act like that myself. If my modules had been in the core for more than two decades, I probably would.