On Mon, Dec 22, 2003 at 01:28:40PM -0800, Stas Bekman wrote:
that will allow several generations of modules with the same name coexist happily on CPAN. Until masses will start complaining I don't see this being resolved.
Mostly because, IMHO, that is not the proper solution to the problem.
If you have a dependent subsidiary product which is specific to the (EG) major revision of some other project, then the first release of the subsid for the new version should be *1.0*, the *product name* should be modified to indicate which version of it's parent it applies to.
Apache 1 and Apache 2 really *are* two separate parents; encoding your dependency in *your own* version number is a recipe for pain.
Nuh, unfortunately that's not a panacea. None of the automatic tools is able to deduct which version to bring based on the version. And that's where the problem is.
The automatic tools don't *have* to: they're *told* which product to install by a human, no?
No, they aren't. In PREREQ_PM in Makefile.PL you specify the minimal version of some module, CPAN/CPANPLUS will bring the latest version which could be quite a wrong choice if there are two generations of this module on CPAN. Here is an example:
PREREQ_PM => {
"Apache::Scoreboard" => "0.12"
}what you get back? 2.01. Right? No.
On the manual installation front, yes, you could try to make it easier, by keeping the same major version number. But what if by the time you wanted to release a new version for generation X, that X has already been taken? In any case, it's the automatic dependency resolving tools which we are having the problem with, not the manual ones.
I believe you've missed my point:
The way you're doing it, you will have exactly that problem.
If instead you name your new apache2 compatible thing Apache2::whatever (*even though the internal naming it carries may be apache:: for functionality's sake) then they won't conflict. And if the internal naming depends on the external naming be right, then you have, so far as I can see, a semi-insoluble problem.
Nope. That's a very bad idea. I don't want to go and rewrite all my code to use Apache2::Request and dozens of other modules, which work exactly the same as before, but their guts are different.
Also I've just released Apache::VMonitor 2.0, which works with both mod_perl generations. So should it be called 1.0? 2.0? It just doesn't work.
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.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
