Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: Checking if your CPAN distributions need to bump their prereq versions (no!)

by tye (Sage)
on Jun 29, 2017 at 02:12 UTC ( [id://1193798] : note . print w/replies, xml ) Need Help??

in reply to Checking if your CPAN distributions need to bump their prereq versions

This sounds like an terrible idea! "Prereq" is short for "prerequisite". It is meant to indicate what version is required for your module to function. It is not meant to indicate which version is the hippest, newest bleeding edge in the repo!

You should specify the oldest possible version of the modules you depend upon. You are supposed to specify the minimal version number, the one that if you can't find one at least that new, then your module can't be installed because it doesn't work with that really old version of the module. A prereq version number does not prevent the installation of a newer version of the module.

Please stop doing this.

- tye        

Replies are listed 'Best First'.
Re^2: Checking if your CPAN distributions need to bump their prereq versions (no!)
by Tux (Canon) on Jun 29, 2017 at 07:16 UTC

    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
Re^2: Checking if your CPAN distributions need to bump their prereq versions (no!)
by stevieb (Canon) on Jun 29, 2017 at 02:17 UTC

    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.

      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.

      - tye        

        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?