Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 57496 invoked by uid 500); 6 May 2002 09:15:16 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 57482 invoked from network); 6 May 2002 09:15:15 -0000 Date: Mon, 6 May 2002 05:14:31 -0400 (EDT) From: Cliff Woolley X-X-Sender: root@deepthought.cs.virginia.edu To: dev@httpd.apache.org Subject: Re: cvs commit: httpd-2.0/include ap_mmn.h In-Reply-To: <20020506082110.15822.qmail@icarus.apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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