On Wed, Feb 15, 2012 at 09:17:57AM -0800, David E. Wheeler wrote:
> You built the distribution with Module::Build version 0.3603, which sets
> versions in the "provides" section to `undef` if there is no version.
>
> I built 0.2.2 with Module::Build version 0.38, which sets missing versions
> in the "provides" section to 0. From the CPAN indexer’s point of view, 0 !=
> undef.
Hmm. That's unfortunate.
> I argue, however, that *all* Lucy modules should have explicit versions.
> Why? Let’s say that I have a module that depends on
> Lucy::Analysis::Analyzer. So I declare in my Build.PL:
>
> requires => {
> 'Lucy::Analysis::Analyzer' => 0,
> }
>
> So far so good, right? But let’s say that I later realize that I need a new
> feature in 0.3.0. Si I change it to:
>
> 'Lucy::Analysis::Analyzer' => '0.3.0',
>
> If someone tries to build, it will fail, because there is no such version.
> In fact, CPAN cannot tell the difference between the
> Lucy::Analysis::Analyzer in 0.3.0 and the Lucy::Analysis::Analyzer in 0.2.2
> or any other release. Because we did not give it a version number. Since the
> best practice is for developers to declare requirements on modules they
> actually `use`, and one may not actually `use Lucy;`, folks may not then
> require a specific version of Lucy, but rather of a module that Lucy
> packages.
>
> So, IME, it is best for every Perl module in a distribution to have its own
> version. This version does not have to change with each release if its
> contents have not changed, but I tend to find that a bit complicated (since
> other modules it depends on may have changed, and those changes might have
> side-effects on my module). So better, IME, is to have the same version in
> every single module in a distribution.
Gotcha.
I really wish that Perl/CPAN version numbers were only associated with
distributions, rather than classes/Perl-packages/modules/scripts/whatever.
I also wish that distribution version numbers were tracked entirely separately
from executable code. Honestly, deriving a version number by eval'ing a
snippet which has been heuristically extracted from Perl module code is a
dreadful hack.
And of course I wish that the CPAN toolchain's version number handling was
not so fragile. I'm leery of changing anything at all about our version
numbers because the system has a tendency to break in all kinds of strange
ways.
Here's a minimalist alternative proposal:
* Don't insert per-package version numbers.
* Verify Module::Build 0.38 or above when running "./Build dist".
Going that route won't add support for the case of requiring a specific
version of individual classes like Lucy::Analysis::Analyzer, but at least it
won't break anything and we can stop burning developer time.
> There are two ways to do this. One is to have this line in every .pm file:
>
> our $VERSION = '0.003001';
>
> Then, before a release (or just after a release, depending on your
> preferences), you would change it every file. I do that with something like:
>
> ack -laiQ 0.003000 | xargs perl -i -pe "s{\QVERSION = '0.003001'}{VERSION
> = '0.003001}g"
>
> Some might find it a bit annoying, but it’s probably the safest way to
> manage Perl module versions.
We don't take chances with updating version numbers. There's a script we run:
devel/bin/update_version
I'm worried about adding all these new version numbers everywhere -- it's a
massive violation of DRY. I predict that we will screw up and miss some in
the future.
Probably we should add a test to ACTION_dist in Lucy::Build that parses the
META.yml and loops over every package under "provides" to verify that it has
the right version number.
> The second way to do it is lazier: Just put this line in every Perl module
> in a distribution:
>
> require Lucy; our $VERSION = eval $Lucy::VERSION;
>
> And yes, it has to be on one line so that Module::Build will parse out the
> one line and eval it. I think this would be safe, though I don’t know if you
> want to load Lucy.pm in every file.
>
> Anyway, best practice is to have an explicit version in every module and to
> make sure it’s properly set for every release.
See my reply to Peter for why this technique poses problems for us.
Marvin Humphrey
