If you, the author, actually need to update the prereqs for your own modules with every release because your own modules fail if they try to use slightly old versions of your own modules, then imagine how painful it must be for people other than you that try to use your modules. Every single time you release a module they have to change their code because your modules lack any useful backward compatibility?

Modules should be modular. That is where the name comes from. Modular code has a defined, narrow interface. Part of the point of the interface being narrow is so that it can also be stable.

You should endeavor to support your own modules being able to work with older (and newer) versions of your own modules. This exercise will help you to better define and to narrow the interfaces that your modules expose.

They don't fail per-se, unless of course a bug is found.

I also add new functionality relatively frequently to a base API wrapper that is needed by multiple other distributions. To ship the new functionality out, it's nice to run one command to let me know which other dists are at which, so I know whether they need to be updated to use said new functionality or not.

It gets more complex when these modules can be brought in by one distribution, or used individually. If for instance the API wrapper module gets added to it a new feature for I2C, obviously I want the I2C distribution that uses that to be updated. I may have also made changes to a part of the SPI code or whatever. Listing out what modules are behind is a good way to understand what is what.

My interfaces are definitely very consistent; I wrote this software to inform me of where I may be lagging behind, and which modules would benefit from a prereq bump. Combined with my auto CI software that tests *all* reverse dependencies of each module (mine and others), I can 100% ensure that external authors' dists will continue to work as well as my own. If my tests fail, I review everything as to what broke, why it broke, and take corrective action.

In this way, I am certain that I haven't broke other modules of mine, other modules of others, and modules of others who use the others (or my) distributions.

It's a pretty sure fire way to ensure the whole CPAN river stays sane.

Curious... do you have any knowledge of other Perl authors who test the whole river each time they go to make a new release?

Here is a basic example.

My WiringPi::API software wraps wiringPi. That library contains many aspects to it, essentially most things you'd want to do on a Raspberry Pi. In my distribution, I also include a bunch of undocumented functions, as well as functions from libraries external to the main code, but within the same project.

My RPi::WiringPi distribution is a housing type retrieval system for a whole bunch of various individual/specific other RPi:: distributions. Example: RPi::I2C, RPi::ADC::MCP3008, RPi::DAC::MCP4922. Some of those individual/specific dists use WiringPi::API and some don't, because I wrote the IC communication myself. So, you can do this:

my $i2c_dev = RPi::I2C->new($dev_addr);
[download]

or, because RPi::WiringPi encompasses/sucks in all sub dists:

my $pi = RPi::WiringPi->new;

my $i2c_dev = $pi->i2c($dev_addr);
[download]

The benefit of this is that the encompassing dist is a one stop shop for all others, but it provides the benefit of ensuring hardware cleanup/reset if there's a crash or other event. The sub modules do not do this. RPi::WiringPi requires WiringPi::API as well for its own business.

If I add functionality to WiringPi::API's I2C functions for example, I obviously need to update the RPi::I2C distribution with the new code. The other sub dists may not require updating to this new version, and that's all well and good.

However, what if I fixed a bug in part of a core function that operates across all dists? I have so many RPi:: distributions that I can't remember without looking. Instead of going to CPAN and checking, I have now a single command that tells me the entire list and what ver they are currently at. I then revdep test every single one, one at a time after making the bump, then once confirmed, I upload each one individually.

This isn't a problem with interface mis-management, or wanting the latest of everything. It was designed as something that would make my life a lot easier, providing me at-a-glance where I am with what. I just thought it may be useful to others for similar (or even dissimilar) purposes, so I added some extra functionality, and published it.