lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David E. Wheeler" <da...@justatheory.com>
Subject Re: [lucy-dev] Failed: PAUSE indexer report KARMAN/Lucy-0.3.0.tar.gz
Date Thu, 01 Mar 2012 18:33:08 GMT
On Feb 29, 2012, at 6:17 PM, Marvin Humphrey wrote:

> I really wish that Perl/CPAN version numbers were only associated with
> distributions, rather than classes/Perl-packages/modules/scripts/whatever.

Only because Lucy requires that everything be loaded. Some distributions ship with a bunch
of modules, but users might use only a subset. As such, they don’t care (or know) what the
distribution version is, only the version for the subset of modules they are using.

Anyway, that ship sailed long ago.

> 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.  

Dreadful? I guess. I don’t do it with any of my modules (other than Bricolage). I always
have constant versions in all my modules, and increment them all to the next version immediately
after a release.

> 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.

Versions are *hard*.

> Here's a minimalist alternative proposal:
> 
>  * Don't insert per-package version numbers.
>  * Verify Module::Build 0.38 or above when running "./Build diet".

No, fail. It’s too late. We already have releases with undef versions and releases with
version 0. Much better to be explicit.

> 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.

But you need to support that case. That's the case that people use.

> 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.

Well, that's why I suggested the hack of `eval`ing. But honestly, it’s not a violation of
DRY unless you have to change them all manually. Run your script to change them all at once,
no repetition necessary.

> 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.

That wouldn’t hurt. Read META.json, though; META.yml is deprecated.

Best,

David
Mime
View raw message