Graham Leggett wrote: > Jim Jagielski wrote: > >> Once we define (and agree) to that, we know how close (or far) >> trunk is. It sounds like we have some set that wants to break >> trunk apart and totally refactor a lot of it, and that's a big +1. >> It's also not a 3-4 month effort :) It also sounds like there >> are people who want 2.4 to be an upgrade to 2.2 as 2.2 was compared >> to 2.4, and a big +1 to that as well. But BOTH of these are using >> the exact same dev branch, and there's no general agreement on which >> we want... if you get my point ;)
Understandable; when we have something suitable for consideration as an alpha, it's time to fork. If we have something in trunk that is clearly not slated for the next version, then we must fork, rm, and tag. Right now I'm not clear that anything in trunk is destined for svn rm from the 2.4 branch. E.g. the mod_proxy devs are just as keen as the aaa <require > refactoring and core httpd devs to put their changes out there in the public sphere, and see what happens. But the moment we have anything that looks like a beta, there is going to need to be a fork. Do you intend that 2.3.x branch -> 2.4.x branch to be C-T-R or R-T-C? > I think the bit that divides these in two is APR v2.0. APR v2.0 is irrelevant, IMHO. It would be nice, but there is plenty of work to do there, and since there are plenty of interfaces in need of renaming and deprecation, out-of-sorts arg lists which can't decide if apr_pool_t * is the first or last arg, by convention (yes, there was a convention), and so on, I don't think we should 'wait' for apr 2. If it beats httpd to release, great. If not, oh well :)
