At 12:32 PM 10/17/2002, Bill Stoddard wrote:
>> One way to summarize this would be: upgrading from a stable release to
>> the next minor number should be painless:
>> config.nice
>> make
>> make install
>> apachectl restart
>>
>> That implies:
>> - No non-backwards compatible config changes (runtime or compile-time)
>> - No removing modules ("deprecating" is fine; that means "to discourage
>> use of", not "to remove")
>> - No MMN changes
>>
>> These rules shouldn't be set in stone: if a security fix or other
>> crucial bug fix requires a MMN change, then so be it. These should just
>> be guidelines.
>>
>> Joshua.
>>
>
>+1 on all of Joshua's comments.
+1 here, too. Joshua, care to encapsulate this thought in ROADMAP?
One bit concerns me, we cannot state that "we will break MMN compat
between security fixes" and "modules are always forward compatible
within a version (e.g. 2.1).
So we have two options;
*) make the bar for breaking the MMN very, very high. I really have never
seen where an MMN *must* have been bumped for a security fix. However,
I agree it could happen.
*) upon such a (very rare) change, do we release the next 2.odd/2.even pair?
The odds are so unlikely I'd suggest we can go with #2. Even the big changes
for Win32 shellcode/PATH_INFO argument fixes were an internal API change,
not external, and that's the biggest security reorg I've seen in a long time.
Bill
