Advice on bumping the mmn

[Jean-Jacques Clar <JJ...@novell.com>]

A new API was added in APR (apr_procattr_addrspace_set()) with changes
bubbling up in httpd-2.0-head.The API is relevant on NetWare and a no-op
on all other platforms. If you look at the status file, the following
entry was added:    *) mod_cgi: Added API call and new field in
apr_procattr_t and cgi_exec_info_t 
       structures to support loading in current or new address space
for CGIs.
       It fixes NetWare that is currently broken after changes done to
log.c r1.145.
...       +1: jjclar, bnicholes
       trawick: is minor mmn bump needed to reflect that API structure
was extended? Should the mmn be bumped up or not?Minor bump is to inform
developers that something has changed that they should be aware of. What
else?Will people that are more knowledgeable please share their
understanding on the subject? Thanks,jjc-:

Re: Advice on bumping the mmn

[André Malo <nd...@perlig.de>]

* Jeff Trawick <tr...@attglobal.net> wrote:

> If Apache adds new field to end of request_rec, that is minor bump, correct?
> Existing modules should continue to work unchanged but modules can choose to
> look at MMN at compile time to see they are being built to work with newer
> Apache and can look at that field.

That's the question. IMHO it's a major bump. It's not strictly binary
compatible, because an existing module could *allocate* the old struct and
pass it to a part of code which is aware of the additional field and wants to
read or write it -> kaboom.

> In this case, a new field was added to end of a different structure passed
> to modules, but why is it different than adding to end of request_rec?

It's not.

... but when did we add a field to request_rec the last time?

nd
-- 
sub the($){+shift} sub answer (){ord q
        [* It is always 42! *]       }
           print the answer
# André Malo # http://pub.perlig.de/ #

Re: Advice on bumping the mmn

[Jeff Trawick <tr...@attglobal.net>]

André Malo wrote:
> * "Jean-Jacques Clar" <JJ...@novell.com> wrote:
> 
> 
>>       trawick: is minor mmn bump needed to reflect that API structure
>>was extended? Should the mmn be bumped up or not?Minor bump is to inform
>>developers that something has changed that they should be aware of. What
>>else?Will people that are more knowledgeable please share their
>>understanding on the subject? Thanks,jjc-:
> 
> 
> Minor bumps are to keep forward compat. (runtime checks are sufficient for new
> features, but a TP module compiled for an older version should run without
> any breakage). Major bumps break binary compat.
> 
> The above is actually a binary compat breakage -> major bump which is strongly
> forbidden in 2.0...

If Apache adds new field to end of request_rec, that is minor bump, correct? 
Existing modules should continue to work unchanged but modules can choose to 
look at MMN at compile time to see they are being built to work with newer 
Apache and can look at that field.

In this case, a new field was added to end of a different structure passed to 
modules, but why is it different than adding to end of request_rec?

Re: Advice on bumping the mmn

[André Malo <nd...@perlig.de>]

* "Jean-Jacques Clar" <JJ...@novell.com> wrote:

>        trawick: is minor mmn bump needed to reflect that API structure
> was extended? Should the mmn be bumped up or not?Minor bump is to inform
> developers that something has changed that they should be aware of. What
> else?Will people that are more knowledgeable please share their
> understanding on the subject? Thanks,jjc-:

Minor bumps are to keep forward compat. (runtime checks are sufficient for new
features, but a TP module compiled for an older version should run without
any breakage). Major bumps break binary compat.

The above is actually a binary compat breakage -> major bump which is strongly
forbidden in 2.0...
One could see it like the mod_ssl.h issue, defining that the APIs were never
part of the public. But my opinion is that we break promises if we do
such things. That's btw the reason why I've made such an effort to wrap the
new 2.1 API of mod_include for the 2.0 backport. And why we need to hide all
non-public stuff in _private.h files or in the .c files themselves _before_
releasing 2.2.

nd
-- 
print "Just Another Perl Hacker";

# André Malo, <http://pub.perlig.de/> #

Re: Advice on bumping the mmn

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

On Fri, 18 Jun 2004, Jean-Jacques Clar wrote:

> A new API was added in APR (apr_procattr_addrspace_set()) with changes
> bubbling up in httpd-2.0-head.The API is relevant on NetWare and a no-op
> on all other platforms.

This alone would not require a MMN bump.

> new field in
> apr_procattr_t and cgi_exec_info_t structures

This, however, would require one, if a module would ever be responsible
for allocating the apr_procattr_t or cgi_exec_info_t themselves, since if
they're and old build, they'd allocate too little space.  With the
apr_procattr_t, I'd imagine the answer is no -- surely APR itself
allocates that.  What about cgi_exec_info_t?

--Cliff

Re: Advice on bumping the mmn

[Jeff Trawick <tr...@attglobal.net>]

Jean-Jacques Clar wrote:
> A new API was added in APR (apr_procattr_addrspace_set()) with changes 
> bubbling up
> 
> in httpd-2.0-head.
> 
> The API is relevant on NetWare and a no-op on all other platforms.
> 
>  
> 
> If you look at the status file, the following entry was added:
> 
>     *) mod_cgi: Added API call and new field in apr_procattr_t and 
> cgi_exec_info_t
>        structures to support loading in current or new address space for 
> CGIs.
>        It fixes NetWare that is currently broken after changes done to 
> log.c r1.145.
> ...
> 
>        +1: jjclar, bnicholes
>        trawick: is minor mmn bump needed to reflect that API structure 
> was extended?
> 

my comment was not about adding the APR routine but about adding a field to a 
structure which is created by Apache and which is potentially is read by 
3rd-party modules implementing that hook called by mod_cgi