+1 for a 2.1 tree Why? :
When a securityproblem/bug is found in 2.0.43, then I excpect to get a new version who is just a "drop-in" replacement for it. What can be accepted is - To have to recompile all modules - Make sourcecode changes to the modules if AND ONLY IF the api change is directly involved with the problem/bug. What can't be accepted is: - Having to change the source of the modules because some API has changed - Changes in the configuration files because of nonrelated changes in apache About one month ago a lengthy discussion why httpd 2.0 is not used very much compared the 1.3.x versions was on this made list. When we now release a 2.0.44 with all the auth changes in it, we will have a reason more to add to this list... If the new version uses a version number like 2.0.43.1 or 2.0.44 is not realy relevant. But in fact it's a branch in the source code and two branches to maintain. So I'm for 2.1 to get all the auth changes done in, and use 2.0.44 for stability. [EMAIL PROTECTED] wrote: >My one thought about this proposal is that it is unclear whether or >not this is attempting to emulate the Perl versioning scheme. If so, >then it's backwards, since Perl uses even numbers for releases and odd >numbers for development, but Bill proposed that 2.1 be the "stable" >branch, and "2.2" become the "development" branch. Linux kernel uses 2.2/2.4/2.6 for stable, 2.1/2.3/2.5 for development. Why not let the 2.0 be the stable one, 2.1 the one with all the auth rewrite in it and when it's ready publish it a 2.2 GA ? André
