Re: cvs commit: httpd-2.0/include ap_mmn.h

[Cliff Woolley <jw...@virginia.edu>]

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.
>
>   Reviewed by:	Cliff Woolley

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
awfully silly to me to start leaving cruft in the structures this early in
the 2.0 cycle, though.  I suggest that we leave this bump in there for
now, and if other changes come about that also could take advantage of an
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.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA

Re: cvs commit: httpd-2.0/include ap_mmn.h

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

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

Re: cvs commit: httpd-2.0/include ap_mmn.h

[Greg Stein <gs...@lyra.org>]

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.

> 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.

>...
> 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.

Note that APR(UTIL) changes will need to be reflected up into Apache's MMN.
I've started a document to describe the APR Group's versioning policy. I'll
post that later this week.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/