> - 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 CGI.pm 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 :) --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
