apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
Date Wed, 24 Nov 2004 19:11:59 GMT
Cliff Woolley wrote:
> On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
> 
> 
>>Allan - your last patches were to try to -wedge- the current
>>API into httpd.  Can you share the patch just to fix APR?
>>Then we can start to comprehend scope.  NO CASTS - just the
>>correct declarations in the first place.
> 
> 
> Since this is obviously going to be big, don't you think it would be
> better to just get going on a sandbox branch of APR so that we can work
> iteratively instead of passing big patches back and forth?

I'm all for using branches if there's going to be some kind of long-term 
breakage caused by the change, but if we're certain that APR 2.0 is 
going to include these changes for 64 bit support in the API then I'd 
much rather see it happen in the trunk, with iterations of the change 
happening there.  Long lived branches should be avoided, IMO, if at all 
possible.  Doing the development that will lead to 2.0 on the trunk 
doesn't keep us from merging changes back into the 1.0.x branch when 
appropriate.

I guess I'm just arguing for a single branch that's the target of the 
current development, as opposed to one 64 bit dev branch and one trunk 
which holds other changes, thus requiring us to either invest constant 
effort in merging changes from the trunk into the 64 bit branch or 
letting it get kind of stale and then having a mega-huge merge into the 
trunk at the end.

-garrett

Mime
View raw message