Geoffrey Young <[EMAIL PROTECTED]> writes: > Perrin Harkins wrote: >>>however, it's not as simple as renaming everything Apache2::*. why? it >>>just doesn't scale well. for example, there are _already_ compat issues >>>between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would >>>need Apache2::* for modules that use the Apache 2.0 API and Apache2.2::* >>>for >>>those that use the 2.2 API. then perhaps Apache3::* someday, etc... >> >> >> I don't really see what the problem is with that. C libraries seem to do >> it that way without too much trouble. What would be the harm in having >> Apache2_2:: and Apache3:: and Apache27:: etc.? It's no worse than saying >> "I want Apache::Foo, but from the 2.2 distribution." > > well, I agree that doing it that way isn't the _worst_ thing that could > happen,
It sure might be, given the apparent confusion between "interface compatibility" and "platform support". Unlike the 1.3|2.0 situation, it's quite possible that a single mp2 source distro will be able to support both apache 2.0 and 2.2; moreover it would make very little sense to support them in a parallel install. If so, users will have to decide which server platform (2.0 or 2.2) they want their mp2 installation to use. Module authors requiring a specific 2.x platform can just *test for it*. If their latest version doesn't support as many platforms as mp2 does, either ask CPAN for multi-version indexing, or just document the issue. But asking the community to embed every incompatible server platform in the package system, just to communicate a platform specification to CPAN? Please, lets not do that. The reason for Apache2.pm is to support parallel installation, nothing more. My only gripe with the mp2 release candidates is that I would have liked to see a few production mp2 releases on CPAN before its mp1 indexing starts to disappear. -- Joe Schaefer -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html