Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3D6FE162.7060702@apache.org>
Date: Fri, 30 Aug 2002 14:19:30 -0700
From: Ian Holsman <ianh@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: what's the hubbub? (was: Re: 2.0/2.1 split)
References: <20020830064839.GT1657@apache.org>
 <5.1.0.14.2.20020830095130.031b2108@pop3.rowe-clan.net>
 <20020830154333.GY1657@apache.org> <20020830171752.GY13980@clove.org>
 <20020830172849.GA1657@apache.org> <3D6FB2D1.9000802@cnet.com>
 <20020830133720.D14402@lyra.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Greg Stein wrote:
> On Fri, Aug 30, 2002 at 11:00:49AM -0700, Brian Pane wrote:
> 
>>Justin Erenkrantz wrote:
>>...
>>
>>>I honestly don't care where this ends up.  It just needs to get
>>>in to our tree somewhere.  The aaa code is broken.  It needs to
>>>be fixed (and I believe the patches we already have start the
>>>process).  2.0, 2.1, 3.0, 1.4 - whatever.  I'm perfectly happy
>>>to break backwards-compatibility.  -- justin
>>
>>I wouldn't object to breaking aaa backward compatibility in 2.0,
>>if it eliminates (for now) the need to start 2.1.
> 
> 
> Hey... I don't believe it is going to break backwards compat [in a big way].
> I'm not sure what the fuss is all about. Since it won't break compat, then
> it doesn't need a 2.1 bump.
> 
> I think in the end, there will be these minor compat problems:
> 
> * some LoadModule lines will need to go away; some added
> 
>   [ and the failure mode here makes this painless; it will be very obvious
>     that you need to toss a LoadModule when Apache says it can't find it.
>     and that you need to load another when it doesn't understand a directive
>     that you had in the file. ]
> 
> * an undocumented feature of AuthUserFile and AuthGroupFile will go away. it
>   is unknown how the hell they worked to begin with.
> 
> 
> I believe that is it. Justin: what else do you think will change from a user
> standpoint?
> 
> And note that the API isn't changing here, either. Justin is adding APIs for
> people, but no changes.

exactly,
this talk of 2.1/branching etc is very premature.
if you think your going to destablize the tree, then do your changes on 
a copy of the file.. and when your done just overwrite the old one.

I'm thinking a in-progress directory should be created for these kind of 
things, simliar to the experimental mpm tree.

what we need most is a stable tree for a couple of months not spliting 
out to a 2.1 tree
> 
> Cheers,
> -g
>