Jonathan Rockway wrote:
I see two resolutions to this problem:
1) Module authors need to re-release their modules whenever
Module::Install is updated.
This is extremely inconvenient, but not a terrible demand. If other
authors are like me, they accumulate small minor changes to their
modules, and then release when something important comes along. A new
M::I is "important" and would force us to keep our "stable" CPAN modules
up-to-date with our svn repositories or whatever. That's a good thing
;) , but probably not the right way of going about it. (For the record,
all my M::I modules use the latest version, and I went to no special
effort to ensure that. So maybe this isn't as hard as it sounds.)
(The right way of going about this, BTW, is out of the scope of this
e-mail... but I do have some ideas...)
Not all authors need to upgrade with every release. I'm trying to note
in the release notes which authors need to upgrade. Sometimes that is
just going to be "anybody using the no_index command manually should
upgrade" or something. But keeping M:I up to date so that your normal
releases get the latest version is very positive.
2) Get M::I into the core of perl, so that everyone has a known-good
tested-everywhere version.
This is the best idea. CPAN works so well because everyone has it and
it's a good piece of software (lately CPANPLUS has gotten rather buggy
and I've gone back to regular CPAN!).
This is _bad_ idea.
Not only is the entire design of Module::Install centered around the
idea that the end-user DOESN'T have to have it installed, but the fact
it has done so well despite what on a normal module would be hideous
failures is a positive.
We can add new commands and new functionality, and the end-user doesn't
have to upgrade.
Further, Module::Install is in no condition to even think of going core
in any case, there are a good dozen issues that are NOT a problem in the
current usage model that would become show-stoppers if we had to put it
into the core and support it forever.
The other solutions (like "kwality" or whatever it's called) are stopgap
measures that don't fix anything.
Oh but they do.
What Kwalitee REALLY does is acknowledge that it's hard for authors to
keep track of all the niggly details, and summarise all the things they
need to fix across their entire set.
This is important for people with 5 or 10 modules. It reduces the amount
of attention and brainpower they have to expend to track problems in the
distributions.
It's absolutely essential for the top 25 or so guys with dozens or
modules, or for the few of us up in the 100 range.
http://cpants.dev.zsi.at/author/ADAMK
Take a look at that list. There's no way in the world I could keep track
of everything.
Kwalitee fixes things ecologically, by providing greater awareness of
problems. And fixing it by derivative methods is still fixing things.
And I for one would be incredibly happy if the list of modules I need to
do incremental releases for to clear out old M:I versions was just a
column on the CPANTS table, as with all the other idea for Kwalitee
metrics that floated across the list (non-executable Makefile.PL et al).
Adam K
