httpd-dev mailing list archives

+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.
gregm@alum.wpi.edu 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é