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
