> From: "Justin Erenkrantz" <[EMAIL PROTECTED]> > Sent: Wednesday, January 02, 2002 4:56 PM > > > > On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote: > > > Broke more than proxy, without a rebuild all. Time for an MMN bump, it seems :) > > > > I was wondering about that. =) What are the rules for a MMN bump? > > You break it, you bump it :) > > Seriously, whenever; > > 1. function declaration or return types change [broken binary compatibility.] > > 2. external structure members change [broken binary compatibility.] > > So when you changed the structs - you needed an MMN bump.
If you add an API or (more controversial) add a new field to the -end- of an existing structure, you bump the MODULE_MAGIC_NUMBER_MINOR. If you change an existing API, add a new field to a structure somewhere other then the end, or modify an existing structure member, you bump the MODULE_MAGIC_NUMBER_MAJOR. Modules compiled against earlier releases of Apache are binary compatabile with all subsequent release of Apache IFF the MMN_MAJOR does not change. Bumping MMN_MAJOR breaks binary compatability with all modules compiled against earlier releases of Apache. > > BTW --- 1.3.23 question here; The API_EXPORT -> API_EXPORT_NONSTD changes in > theory require an MMN bump on Win32. Which really sucks, because I don't want > to break everyone else. Anyone given any thought as to how we can avoid an MMN > bump, when all that's happened is a specific platform has been broken [linkage, > etc?] It almost makes me think we _aught_ to drop the .def file for win32, > creating decorated symbol names that now-broken modules will refuse to link > against, sparing all other platforms a version bump. I -think- we can ditch the .def file. I'm a bit concerned that we might break something unexpected... Also need to bump the MMN_MAJOR. Doing anything else is a kludge that could introduce more problems than it solves. Bill
