In fact you should do BOTH! State the minimum required and state the recommended version. The latter should have been thoroughly tested.
Having a lowest supported and a recommended might have a lot of added value to a module. Say that the newest/hippest module adds a feature that can speed up you code by a factor 10, it is worth supporting that with a fallback to the old code if the newest feature is not available.
You META.yml might then have a section similar to:
requires:
perl: 5.008001
DBI: 1.628
DBD::File: 0.42
SQL::Statement: 1.405
Text::CSV_XS: 1.01
recommends:
DBI: 1.636
DBD::File: 0.44
SQL::Statement: 1.412
Text::CSV_XS: 1.31
configure_requires:
ExtUtils::MakeMaker: 0
DBI: 1.628
build_requires:
Config: 0
test_requires:
Test::Harness: 0
Test::More: 0.90
Encode: 0
Cwd: 0
charnames: 0
test_recommends:
Test::More: 1.302085
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l] |
I will review my observation of all of this. It was supposed to be something that showed with *my* distributions had prereqs of *my* software that were behind.
I had no idea that it would cause such a furor.
If my WiringPi::API software had issues, why shouldn't I know which other of my dists have that outdated versions of it?
It's not like it auto-updates or something.
This distribution simply *informs* you what is out of date. What's the problem with that?
I should repeat again that the default shows the author's distributions along with their own software that is out of date. You have to go out of your way to see a full blown list of all prereqs outside of one author's scope.
| [reply] |
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.
| [reply] |
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?
| [reply] |