httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: Auth: Start the httpd-2.1 branch finally?
Date Sun, 13 Oct 2002 17:30:00 GMT
At 05:59 AM 10/13/2002, Greg Stein wrote:
>The API *is* stable. The auth changes did nothing to the API except to
>expand it a bit for *new* auth systems. Existing auth modules are
>unaffected.

To the extent that they don't choose to use the new hooks, I believe
you are right.  Certainly no MMN major bump required.  The reorganization
is the only issue, and only from a user perspective, not a coding objection.

>There were some directive changes, and certainly some different modules to
>load, but nothing in the API department. Moreover, I think we can deal with
>the directives and create some kind of backwards-compat stuff. It is just
>that I'm not entirely sure what got dropped and added yet. The modules are a
>bit tougher. We could potentially fix it with hacks to the module loading
>stuff to key off the old names and load the new stuff, but that just feels
>fugly...

Exactly my point.  Few understand what got added and dropped.
It's a mess from an administrators point of view.

The *code* is good.  The reorganization is the hardship.  Projects shouldn't
(and most would never) demand that users reorganize their configuration
files on a subversion point bump.  

So far, Two Bills beg that we defer the auth reorg to 2.1.  If I hear three, 
I will consider it appropriate to veto the auth reorganization for 2.0, until 
we start 2.1.  The technical justification would be unreasonable support 
traffic (via bugzilla, user lists, etc) in response to administrators as
they are forced through this update.  Technically, a reasonable demand
for a version point bump, but not reasonable within a subversion point bump.

Don't get me wrong, I'm ++1 for this change to Apache 2.1, and want to
help folks develop to the new schema for Apache 2.1.  I suggest a 2.1 
branch for affected files, for now.  This makes it simple, when we officially
begin the 2.1 "Effort", to merge all the changes from the main branch
and incorporate all 2.1 changes.  Only the folks who commit code to
the 2.1 branch are committed to remerging the changes from HEAD.
Folks not interested in participating yet would not be affected by this
side branch.

I still think it's silly to insist that 2.0 be 'perfect' when we can easily
drop support of 2.0 once 2.1 it is just as ready for the prime time.
The 1.3 tree remains supported simply because it is more portable, 
the lack of thread support makes it less complex and therefore 
(so far) a bit more robust on Unix, and there is a rich history 
of modules which {won't be /or/ are still being} ported.

Other thoughts, suggestions or objections?

Bill


Mime
View raw message