- or documentation issues should be addressed by them.
-
-* Minor releases can introduce new "safe" features, do non-trivial
- but mostly safe code clean-ups, and even add new runtime warnings
- (rigorously non-fatal); but they shouldn't include any backward
- incompatible change, nor contain any potentially destabilizing
- refactoring or sweeping change, nor introduce new features whose
- implementation might be liable to cause bugs or regressions in
- existing code.
-
-* Major releases can introduce backward-incompatibilities (albeit
- such incompatibilities should be announced well in advance, and
- a smooth transition plan prepared for them), and try more risking
- and daring refactorings and code cleanups.
+ or documentation issues should be addressed by them. On the other
+ hand, it's OK to include testsuite work and even testsuite refactoring
+ in a micro version, since a regression there is not going to annoy or
+ inconvenience Automake users, but only the Automake developers.
+
+* Minor releases can introduce new "safe" features, do non-trivial but
+ mostly safe code clean-ups, and even add new runtime warnings (rigorously
+ non-fatal). But they shouldn't include any backward incompatible change,
+ nor contain any potentially destabilizing refactoring or sweeping change,
+ nor introduce new features whose implementation might be liable to cause
+ bugs or regressions in existing code. However, it might be acceptable to
+ introduce very limited and localized backward-incompatibilities, *only*
+ if that is necessary to fix non-trivial bugs, address serious performance
+ issues, or greatly enhance usability. But please, do this sparsely and
+ rarely!
+
+* Major releases can introduce backward-incompatibilities (albeit such
+ incompatibilities should be announced well in advance, and a smooth
+ transition plan prepared for them), and try more risking and daring
+ refactorings and code cleanups.