perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: nuking old mod_perls before installing unstable
Date Wed, 23 Mar 2005 13:27:56 GMT

Joe Schaefer wrote:
> Adam Kennedy <> writes:
> [...]
>>The version of the implementation is not the same as the
>>version of the API. If Apache2:: can be kept compatible 
>>(or "almost" compatible) then there is no need to increment
>>the API version, regardless of whether the implementation
>>version goes to 2.2 or 2.4 or 3. 
> Agreed.  I also don't see why renaming Apache::RequestRec to
> Apache2::RequestRec requires any current mp2 module authors
> to rewrite their code.   We just need to provide the original
> Apache:: APIs for them as well.  
> The neat thing is, we know who those guys are because they 
> all "use Apache2".  Since it's apparently been removed from 
> the branch, maybe we should think about restoring that module,
> and rewriting it so that it just provides all the current APIs
> instead of mucking around with @INC.

I don't mean to be a pain or unaware of the pains this might cause
developers during the transition, but I think this is a really bad idea.

we provide Apache::compat because it's not intuitive that, say,
register_cleanup() is now cleanup_register().  what we're doing here is
entirely different.

providing a compat layer for prior, non-2.0 releases of mod_perl just
reinforces the idea that it's ok to use either namespace.  we'll get
questions on support lists about Apache::RequestRec, people looking for
Apache/, create another debug layer to test and worry about,
and so on.

I feel very strongly that if Apache2:: becomes the official namespace of mp2
then that's it - this is the API.

yeah, this might seem like I don't care about developers or their time, but
I do - forcing a move means that the break is clean, simple, and completely
over with before we're at 2.0.  it doesn't keep a mistake lingering around
to bite anyone down the line, such as when we're at 2.0.15 and decide it's
time to remove "the thing that lets people run old 1.99-style code" and
things suddenly start breaking in production.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message