perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject nuking old mod_perls before installing unstable
Date Tue, 22 Mar 2005 14:00:51 GMT

>   - you cannot make, test, or install the unstable branch over any
>     other version of mod_perl-1.99

ok, let's talk about this specific detail in another thread :)

I've pretty much layed out my own thoughts on why I think this needs to be,
but I'll do so again here.

basically, my position is that mod_perl is not at 2.0 yet, so until it does
the entire API is up for grabs.  now, realistically taking that stance over
and over again will just upset the userbase, so we don't really change the
API all that often, and it's pretty solid and dependable as it stands.
however, in this instance, we're (potentially) talking about a major
namespace shift that will break absolutely everything in existence to this
date.  we all know that is the ramifications of the proposal on the table.

so, given that, what do we do about our installed 1.99_XX userbase.  my
opinion is that we can't really help them, or help them and keep our own
sanity, at least.  making a clean break at this point makes cerain that we
have only two official APIs - 1.0 and 2.0.  providing any kind of back
compat to prior 1.99 versions, or even allowing prior 1.99s to exist with
(the proposed) API essentially means we are "supporting" 3 APIs.  by
supporting I mean we'll end up saying on mailing lists "nuke your old 1.99
install and try again" when things to awry, thus wasting precious cycles.

so, in the end I think mod_perl, should it choose to adopt this renaming
scheme, needs to make a clean break and practically deny the existence of
any other API internally.  modules like can then decide internally
how they want to handle their userbase - provide support for old mod_perl
API versions or only deal with 2.0, however it evolves.

so, if there is a difference of opinion on this particular issue that's fine
- let's discuss it :)  but we need to understand the full ramifications of
allowing 1.99_20 and 1.99_22 in the same site_lib (or not) and have them
spelled out.  or spelled out for me, at least, since I don't see how we have
any other choice here if we don't want to be supporting 3 APIs (which I, for
one, don't :)


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

View raw message