2.0, 2.1 branch, WAS: Re: Renames

[Sander Striker <st...@apache.org>]

Jeff Trawick wrote:

>Thom May <th...@planetarytramp.net> writes:
>So what is the consensus with the renames? The patch is available from
>http://cvs.apache.org/~thommay/full-rename-diff and seems good - it builds
>and passes tests on (at least) BeOS and OS X.
>Also, httpd and svn don't need any changes to still work - the functions are
>all wrapped by the old names. So it's just binary compatibility that's the
>problem.
>
>
>But binary incompatibility breaks the notion of a stable httpd API.
>Can we hold off until Sander tags everything for an httpd release?
>(I guess Sander is still planning to tag.)
>
Always useful if Sander responds ;)  Bottom line: I'm not going to tag 
before we branch.
It all comes down to this:
- The auth changes _don't_ break 3rd party auth modules
- We can rename the auth modules and their directives back to their old 
names
  so we don't break existing 2.0 configs
- We must add implicit loading of mod_auth_basic when no auth provider
  was loaded
- AFAIK the renames don't break bin compat, everything is wrapped in stubs

So, we're ok.  We can branch right now, because the state of the tree today
is probable what we want to use as the basis for 2.1/2.2.

Once we get the auth stuff renamed and the implicit loading in place I'll
tag 2.0.44.  My guess is that this will probably happen next week somewhere.
Justin?

Jeff, OtherBill, does httpd-2.0 HEAD contain anything you'd rather not see
rolled into 2.0.44 (apart from the above)?


Sander

Re: 2.0, 2.1 branch, WAS: Re: Renames

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 03:09 PM 11/20/2002, Sander Striker wrote:
>Jeff Trawick wrote:
>
>>Thom May <th...@planetarytramp.net> writes:
>>So what is the consensus with the renames? The patch is available from
>>http://cvs.apache.org/~thommay/full-rename-diff and seems good - it builds
>>and passes tests on (at least) BeOS and OS X.
>>Also, httpd and svn don't need any changes to still work - the functions are
>>all wrapped by the old names. So it's just binary compatibility that's the
>>problem.
>>
>>
>>But binary incompatibility breaks the notion of a stable httpd API.
>>Can we hold off until Sander tags everything for an httpd release?
>>(I guess Sander is still planning to tag.)
>Always useful if Sander responds ;)  Bottom line: I'm not going to tag before we branch.
>It all comes down to this:
>- The auth changes _don't_ break 3rd party auth modules
>- We can rename the auth modules and their directives back to their old names
> so we don't break existing 2.0 configs
>- We must add implicit loading of mod_auth_basic when no auth provider
> was loaded
>- AFAIK the renames don't break bin compat, everything is wrapped in stubs
>
>So, we're ok.  We can branch right now, because the state of the tree today
>is probable what we want to use as the basis for 2.1/2.2.
>
>Once we get the auth stuff renamed and the implicit loading in place I'll
>tag 2.0.44.  My guess is that this will probably happen next week somewhere.
>Justin?
>
>Jeff, OtherBill, does httpd-2.0 HEAD contain anything you'd rather not see
>rolled into 2.0.44 (apart from the above)?

Diff'ing 2.0.43 include/ I don't see any changes externally that would affect
any third party modules, except the most obscure.  It's probably best to
simply pound on the code through the usual regressions (I'm attempting
to create ISAPI regressions from the MSDN samples, provided a Win32
user has the MSDN installed and patched to fix MS's bugs in their
ISAPI samples.)  I'll collect that patch and those tests (my first attempt
to build any new stuff in perl-framework) and run those regressions this
weekend.

And if I can find the right solution to fix the SSL HTTP over HTTPS error
result regression we should get that back to HTTP/1.0 for release 2.0.44.

Bill

Bill