Dominique Quatravaux wrote: [...]
I think all of these folks are quite able to do a quick s/use Apache::/use Apache2::/ or something: none of the proposals so far are rocket science, really. Actually we can (and are eager to!) deal with
I'm afraid this is exactly where people fail to see the problem. It's not a simple rename. Many companies and CPAN developers need to support a code base running under more than one generation of mod_perl. Untill now, with a few little changes or sometimes with no changes at all (depending on what API was used) they could have the code running under mp1 and mp2. With this rename they either need to split their code and maintain different versions, which are otherwise identical, or have an unmaintable code at best. Now what you gonna do when mod_perl 2.2 is released? have a third split to maintain? and 2.4? and 2.6, and 3.0? even if the majority of the API hasn't changed. That sucks, sucks, sucks!
Show me any big successful project whose product is a public API and who embeds the API numbers in the API. I doubt you will find one that is successful and having a wide adoption. Why? Because nobody wants to rewrite their application and have a hell of time maintaning those when a new major version is released
Embedding version numbers in the API is wrong. mod_perl should *not* do that.
I don't really want to raise the issue of CPAN again. Just to remind you, that CPAN can evolve and support the needs of its users. mod_perl is not the first project to suffer from its limitations. Crippling the API to workaround the CPAN limitation is not the best way to solve the problem. Luckily the automatic CPAN tools can be totally ignored and you will still be able to install any module that you will need, granted you will need to figure out the right version to download first.
-- __________________________________________________________________ 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
