perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: mod_perl 2.0 namespaces - a proposal
Date Tue, 22 Mar 2005 12:26:05 GMT


Joe Schaefer wrote:
> Geoffrey Young <geoff@modperlcookbook.org> writes:
> 
> [...]
> 
> 
>>I really don't see how it can be any other way - I absolutely,
>>positively do not want to deal with questions about how prior beta
>>versions mix with later beta versions and, eventually, the official
>>2.0.
> 
> 
> So then, the proposed branch is a regression over trunk?

if you mean incompatible, yes.  and that was obviously going to be the case
if things are renamed.

> Hmm, that'd surely get a veto vote from me (assuming we do
> allow vetoes).

I really don't see how it can be any other way.  the point of this entire
exercise was to come to a decision so we could officially bless 2.0 and move
on.  not to be a pain about it, but the API was officially not the official
API until 2.0 is released - that's why it's taking so long.  as such, I
don't think we have any obligation to support prior 1.99 versions.  what
we're doing here is figuring out what the official 2.0 will look like.

taken another way, we didn't worry about prior 1.99 versions each time we
added pools as an argument, took pools away, made things methods or
functions - it was part of the evolution of the software.  granted this is
bigger, but it's the same thing.  couple this with users complaining because
they installed 1.99_20 last month and are upgrading and things aren't what
they are supposed to be and you have a support nightmare.  at least this is
a clean separation starting now.

> 
> Since we're apparaently new to all this formal voting stuff, 
> how about we first have a vote to adopt this tried-and-true document:
> 
>      http://incubator.apache.org/learn/rules-for-revolutionaries.html

I'd really hate to see mod_perl start to operate that way.

> I think we MUST have
> a process which allows everyone to express their votes.

I wasn't suggesting otherwise.  but this is entirely different than vetoing
the addition of some api.  we have the current namespace and the proposed
namespace.  perhaps there is a third option, but I doubt it since nobody was
able to figure one out.  however, a decision needs to be made.  I, at least,
will not play around with this branch forever, or even for another month -
we need to figure out the way mod_perl will look from now on, do it, and
move on.

--Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message