Consistent version metric based on false premise

[rwfranks]

Consistent version test is based on the false premise that all components of a distribution share a common version number.

It is entirely reasonable that there be at least one component with the distribution version number as advertised in the META.yml and/or META.json metadata (which themselves should be consistent).

There are three cases to consider:

1) Exactly one component has the advertised version from distribution metadata. The remaining components each have version histories of their own, managed by some other version control system. The component versions persist across many distribution versions.

2) More than one component has the advertised version from distribution metadata. Existing test is correct in expecting that remaining components have same version.

3) No component version matches the distribution metadata. Test fails because metadata is inaccurate or distribution assembled from wrong components.

The examples I have in mind are Net::DNS and Net::DNS::SEC, both of which have many components with long lifetimes.

[charsbar]

It's not a false premise.

Consider you are a package manager who need to collect all the necessary distributions for your company etc. You probably get a list of prerequisites from Makefile.PLs/Build.PLs or by scanning all the files in your projects. Now you know required modules and their versions, you look for distributions that have those modules. You visit a CPAN search site, search modules by their names, and find a bunch of distributions that have the same version as the required module version. Unfortunately, however, you are not sure for some, and start looking for the details. You can't easily find the versions of modules in a distribution at MetaCPAN (as of this writing). You probably have to move to search.cpan.org but the version you find first doesn't match to the required version. Actually there seems no distribution that has the same version as the required module version. You go through all the releases and find some of them have the module of the version. Probably you should read Changes to decide exactly which of them you require, but you are so tired now that you just fetch the latest of them. Let's hope it's the correct one. It's not sometimes.

In another case, you find from a news feed you subscribe that a newer version of the required distribution is released, with a note that there was a security issue in the older versions and all of you are recommended to upgrade. Unfortunately you have forgotten the version of the module you actually require from the distribution doesn't always match the version of the distribution. You just update the version in PREREQ_PM in your Makefile.PL with the version of the latest distribution, without changing the name of the required module, and rashly ship your distribution that depends on it. You'll soon get a report that says there's no module with that version on the CPAN.

These are just two examples to show you why all components of a distribution should share a common version number. You'll find more when you try to uninstall modules, or move modules into other distributions, or even when you try to fix the problem.

Note also that Changes files in the two distributions you mentioned don't show any information on the subordinate $VERSIONs from revisions in other repositories. It may be meaningful for the authors/contributors of the distributions, but almost useless for other users.

If you need something more real, older versions of CGI.pm distribution or libwww-perl distribution or maybe HTML-Parser distribution will give you a clearer insight: consider you depend on different versions of CGI.pm and CGI::Cookie, or LWP::UserAgent and LWP::Simple, or HTML::Parser and HTML::Entities etc.

Anyway, users don't know (or even care) if inconsistent versions in a distribution are due to other well-managed version control system or bundling several closely-related modules. All they want to know is if they need to install/upgrade a certain version of a distribution or not and so on, and what makes it harder is simply bad for them.

[rwfranks]

On 23 May 2015 at 05:45, Kenichi Ishigaki notifications@github.com wrote:

It's not a false premise.

Consider you are a package manager who need to collect all the necessary distributions for your company etc. You probably get a list of prerequisites from Makefile.PLs/Build.PLs or by scanning all the files in your projects. Now you know required modules and their versions, you look for distributions that have those modules. You visit a CPAN search site, search modules by their names, and find a bunch of distributions that have the same version as the required module version. Unfortunately, however, you are not sure for some, and start looking for the details. You can't easily find the versions of modules in a distribution at MetaCPAN (as of this writing).

If I ever had to do that, I would consider that I had already lost control of my project and richly deserve to be fired!

40 years of software development, 15 years of which involved building development and configuration management tools for very large projects with millions of lines of code, taught me that insisting that each component of a distribution be tagged with the same revision number quickly becomes unsustainable when the number of components becomes large.

I suggest you take a step back, and think a little more carefully about the simple proposition outlined in my PR.

What I am asking for, is more accommodating behaviour towards developers who, for legitimate reasons of their own, do not subscribe to your view of the world. The goal of the test should be to catch unintended mistakes in version numbering rather than attempting to coerce developers to change their version numbering policies.

I will be more than happy to work with you to design an improved test.