MMN, versioning, WAS: Re: svn commit: r219372 - in /httpd/httpd/trunk ...

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

William A. Rowe, Jr. wrote:
> At 12:12 AM 7/17/2005, ianh@apache.org wrote:
> 
>>Author: ianh
>>Date: Sat Jul 16 22:12:10 2005
>>New Revision: 219372
>>
>>URL: http://svn.apache.org/viewcvs?rev=219372&view=rev
>>Log:
>>This patch adds a new hook (request_status) that gets ran in proxy_handler
>>just before the final return.  This gives modules an opportunity to do
>>something based on the proxy status.
>>[...]
>>new hook -- so mmn bump.. i made it a major one, hope thats ok 
> 
> 
> We only bump major when we -change- an existing API or drop an
> API which is no longer supported.  E.g. anyone using the old
> major might have been using something we no longer provide.
> 
> A new structure member (at the end of an httpd-allocated structure)
> or new function are minor bumps; which this patch falls under.
> The user updating should not need to update their module, because
> the expectations when such modules were built have not changed.

Well honestly, the way the MMN is bumped has been very arbitrary.

If we want to go by the rules that you describe, it needs to get
documented.

One might actually wonder what the MMN is good for nowadays anyway,
given that we have provider versioning and better defined overall
versioning (ie. API compatibility between minor versions).


Sander

Re: MMN, versioning, WAS: Re: svn commit: r219372 - in /httpd/httpd/trunk ...

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

* Sander Striker wrote:

> Well honestly, the way the MMN is bumped has been very arbitrary.

If so, then by accident. I also have an eye on bumps.

> If we want to go by the rules that you describe, it needs to get
> documented.

/*
 * MODULE_MAGIC_NUMBER_MAJOR
 * Major API changes that could cause compatibility problems for older 
modules
 * such as structure size changes.  No binary compatibility is possible 
across
 * a change in the major version.
 *
 * MODULE_MAGIC_NUMBER_MINOR
 * Minor API changes that do not cause binary compatibility problems.
 * Should be reset to 0 when upgrading MODULE_MAGIC_NUMBER_MAJOR.
 *
 * See the MODULE_MAGIC_AT_LEAST macro below for an example.
 */

Looks like it is in ap_mmn.h :-)

> One might actually wonder what the MMN is good for nowadays anyway,
> given that we have provider versioning and better defined overall
> versioning (ie. API compatibility between minor versions).

It's a compatibility promise. Or in other words the MMNs *are* the 
versioning scheme for all static APIs. We should just keep it so :)

nd
-- 
Wer sein Wissen nicht teilen will, besitzt wahrscheinlich zu wenig davon.
  -- Unbekannt