> At the risk of racing too far ahead in this discussion, here is my > suggestion... 2.0.43 becomes 2.1 and the MMN major does not change > for subsequent 2.1 series releases (except for a compelling reason, > eg a security fix -requires- a bump). Why 2.1? No technical > reason; purely a PR tactic to telegraph to the user community we > are putting a lot of focus on maintaining binary backward > compatability and to get rid of the *.0.* in the version number > (yea, to appease the folks who are allergic to 0's in version > numbers).
Here's my fundamental concern: where do we do the bulk of development (new features)? Do we no longer have 2.0 releases? Do we close 2.1 to new features (only security fixes)? More precisely, who dictates what goes into 2.1 or 3.0? If the sole criteria is MMN bump, the auth changes didn't cause a bump of the MMN. So, then, does it belong in 2.1? When can we remove (or rename) a module - is that a version bump? What if we add a module - version bump? What if APR changes a function prototype - does that require a version bump? What if we change the meaning of a directive (say TAKE12 to TAKE1)? What if we add (or delete) a directive? If we decide to split off 2.0 into two trees (2.1/3.0 as you suggest), then what is the criteria for 3.0 supplanting 2.1? What is the expected lifetime of 2.1? What is the expected lifetime of 3.0? Should we expect a 2.2? What is the policy for backporting fixes? What is the policy for forwardporting fixes? (Surely no one can suggest that 2.0 is bug-free.) Do you wish to allocate resources for maintaining each branch (a la Linux which has open 2.2/2.4/2.5 trees and a dedicated maintainer for each)? I'd prefer to come up with strict versioning rules for httpd before proceeding further. I'm slightly concerned that we're starting to move away from the 'versions are cheap' ideology. Currently, we place no meaning on the version numbers (only the quality of the tarball). I think we ought to step back and place a meaning on the versions first. -- justin
