Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
From: =?iso-8859-1?q?Andr=E9_Malo?= <nd@perlig.de>
Organization: TIMTOWTDI
To: dev@httpd.apache.org
Subject: Re: MMN, versioning,
 WAS: Re: svn commit: r219372 - in /httpd/httpd/trunk ...
Date: Sun, 17 Jul 2005 20:45:23 +0200
User-Agent: KMail/1.8.1
References: <20050717051213.42436.qmail@minotaur.apache.org>
 <6.2.1.2.2.20050717104231.043137d0@pop3.rowe-clan.net>
 <42DA9FE7.4050200@apache.org>
In-Reply-To: <42DA9FE7.4050200@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507172045.23715@news.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