httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: httpd-2.0/include ap_mmn.h
Date Tue, 07 May 2002 20:44:18 GMT
At 02:09 PM 5/7/2002, you wrote:
>On Mon, May 06, 2002 at 05:14:31AM -0400, Cliff Woolley wrote:
> > On 6 May 2002 jerenkrantz@apache.org wrote:
> >
> > > jerenkrantz    02/05/06 01:21:10
> > >
> > >   Modified:    include  ap_mmn.h
> > >   Log:
> > >   Removing a field in a core structure (r->boundary) merits a MMN bump,
> > >   unfortunately.  They got 2 GAs out of the old MMN.
>
>Well, I think that 2.0.36 should have had one, given the API changes that we
>made to APR and other parts.

No, it wasn't necessary.  I posted a summary of all API changes .35->.36 and
there were no public structures, or httpd, apr or apr-util APIs affected.  One
dubious point was the side-channel optional function for cgi which allows
mod_win32 to rewrite command execution for that platform (registry based
invocation, etc.)

> > If people end up objecting to this (I'm sure they will :-P), we *could*
> > just leave a dummy field in the middle of the request_rec.  It seems
>
>That would give you binary compat, but not semantic/compilation compat.
>Thus, you still need the MMN bump.

Huh?  No, if this is an internally used flag, who really cares if it is 
meaningful.
If it needs to be advertised, we can set the flag till we deprecate the field.
It sure doesn't seem like the sort of value that 3rd party modules should set.

> > MMN bump, we won't feel too bad about it.  If we get to release time and
> > this was the only change, we can consider sticking in a dummy var as a
> > *temporary* measure at that time.
>
>People will need to be more rigorous about MMN bumps so that we can see what
>other API changes were made.

We have been [although not instantly.]  Sort of like you suggest, most 
bumps have
been 11th hour flags that we needed the compat break.

If it helps, I will probably introduce the apr_finfo ctime -> itime/ftime 
split (for inode
change and file creation timestamps) sometime over the next week or two, 
and that
will [unfortunately] break binary compatibility.

Bill


Mime
View raw message