+============================================================================
+= Automake versioning and compatibility scheme
+
+* There are three kinds of automake releases:
+
+ - new major releases (e.g., 2.0, 5.0)
+ - new minor releases (e.g., 1.14, 2.1)
+ - micro a.k.a. "bug-fixing" releases (e.g., 1.13.2, 2.0.1, 3.5.17).
+
+ A new major release should have the major version number bumped, and
+ the minor and micro version numbers reset to zero. A new minor release
+ should have the major version number unchanged, the minor version number
+ bumped, and the micro version number reset to zero. Finally, a new
+ micro version should have the major and minor version numbers unchanged,
+ and the micro version number bumped.
+
+ For example, the first minor version after 1.13.2 will be 1.14; the
+ first bug-fixing version after 1.14 that will be 1.14.1; the first
+ new major version after all such releases will be 2.0; the first
+ bug-fixing version after 2.0 will be 2.0.1; and a further bug-fixing
+ version after 2.0.1 will be 2.0.2.
+
+* Micro releases should be just bug-fixing releases; no new features
+ should be added, and ideally, only trivial bugs, recent regressions,
+ 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.
+
+* For more information, refer to the extensive discussion associated
+ with automake bug#13578.
+
+============================================================================