On Mon, Dec 22, 2003 at 02:35:40PM -0800, Stas Bekman wrote:
> >>what you get back? 2.01. Right? No.
> >
> > Which sort of *makes* my point: they're *two separate modules*.
> > They're not 2 different versions of the same module.
>
> Yes and No, depending on how you look at it.
Yeah. The problem is that the "top" API is (roughly) the same, but the
"bottom" API differs markedly; it's a problem common to all glue.
> >>>If it doesn't depend on the major version of the parent, then this
> >>>entire conversation doesn't apply to that module, no?
> >>
> >>It does if you suggest to deduct which version this module is designed for
> >>from its version number.
> >
> >
> > <sigh>
> >
> > *You* are suggesting that.
> >
> > *I* am suggesting that you deduce it from the *name*. I am saying that
> > you *cannot* reliably deduce it from the version number, precisely
> > because you are *overloading* the version number, giving it semantics
> > it should not have.
>
> OK, right.
>
> The point of my comment in the original announcement wasn't start this thread
> again, but to get things done. The issue with your suggestion is that nowadays
> we hardly ever do things manually, because we use search.cpan.org or CPAN.pm
> to tell us what and where the package is and they will fail to do that the way
> things are today.
"Again"? Oh.
> Here is what needs to be done:
>
> - META.yml needs to support a new key: product_generation, so module authors
> can mark their module with the generations their module support. it should be
> a key/val thing:
>
> product_generation:
> mod_perl: 1.0
>
> a module can define several generations.
>
> - PAUSE indexer needs to index the higher version number for each
> product_generation if such exists and not just the highest number.
>
> - search.cpan.org/CPAN.pm/CPANPLUS aka CPAN clients need to present the
> highest numbers of all available generations, unless you have asked them for a
> specific version. So whenever you ask any of these CPAN clients to give you
> Apache::Scoreboard, they should say,:
>
> oh, dear, looks like I have several matches for this module:
>
> version generation
> Apache::Scoreboard 0.10 mod_perl 1.0
> Apache::Scoreboard 2.01 mod_perl 2.0
>
> which one do you want [2.01]?
>
> - since we don't like propmts CPAN clients should be instrumented to let us
> tell them what's our preferred generations are. I'm not sure about
> search.cpan.org, but for CPAN.pm/CPANPLUS I want to be able to tell these
> tools about my preferences. So if I'm going to build 3rd party tools for
> generation 'mod_perl: 2.0', I'd like to start CPAN.pm like so:
>
> % CPAN_GENERATIONS="mod_perl: 2.0" perl -MCPAN -eshell
>
> or similar.
>
> - PREREQ_PM needs to support ranges, like Module::Build prerequisites do. So
> if Apache::VMonitor for mod_perl 1.0 needs Apache::Scoreboard for mod_perl
> 1.0, it can ask for it:
>
> PREREQ_PM => {
> "Apache::Scoreboard" => "> 0.12, < 2.00",
> }
>
> -------------------
>
> Once all the above is done, authors will need to release updated packages to
> include the updated META.yml with the right generation numbers and Makefile.PL
> PREREQ_PM fixes. And we are all set.
>
> p.s. remember that the discussed issue is *not* a unique to mod_perl problem.
> There are several other modules with the same issue. For example GD, which has
> at least 3 generations on CPAN.
Oh yeah, it was quite clear to me that it was an infrastructural
problem. But yes, breaking it out into another datum will solve most
of the problem. I'm still not happy with overloading it into the
version number rather than the name, but perhaps there are couplings
between the "internal" (module calling) and "external" (packaging)
namespaces of which I'm not aware. If so, a pox on the house of
whomever designed that system.
Sorry to waste your time, Stas.
Cheers,
-- jra
--
Jay R. Ashworth [EMAIL PROTECTED]
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
Come see Linux Gazette in our new home: www.linuxgazette.net!
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
