Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42DA9FE7.4050200@apache.org>
Date: Sun, 17 Jul 2005 20:13:59 +0200
From: Sander Striker <striker@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: MMN, versioning, WAS: Re: svn commit: r219372 - in /httpd/httpd/trunk
 ...
References: <20050717051213.42436.qmail@minotaur.apache.org>
 <6.2.1.2.2.20050717104231.043137d0@pop3.rowe-clan.net>
In-Reply-To: <6.2.1.2.2.20050717104231.043137d0@pop3.rowe-clan.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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