maint: describe new versioning and branching scheme, and adjust to it

See discussion about automake bug#13578 for more details and background.

Basically, for the versioning scheme:

  - micro versions only for bug and regression fixing;
  - minor versions for new backward-compatible features, and new
    non-fatal deprecations;
  - major versions for backward-incompatibilities, complex new
    features, and major refactoring.

And for the git branching scheme:

  + branch 'next' is for the upcoming major version;
  + branch 'master' is now for the upcoming minor version;
  + branch 'maint' is for the upcoming micro (bug-fixing) version;
  + the merging hierarchy is: 'maint' -> 'master' -> 'next'.

* HACKING (Automake versioning and compatibility scheme): New.
(Working with git): Adjust.
* NEWS: Update and fix.
* aclocal.in: Adjust some "FIXME" messages.
* automake.in: Likewise.
* m4/mkdirp.m4: Likewise.
* t/aclocal-acdir.sh: Likewise.
* t/aclocal-macrodir.tap: Likewise.
* t/aclocal-macrodirs.tap: Likewise.
* lib/Automake/Options.pm: Likewise.
* m4/internal/ac-config-macro-dirs.m4: Likewise.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>

1 files changed, 50 insertions, 9 deletions

diff --git a/NEWS b/NEWS
index f9a1fb17c..1ea9fa638 100644
--- a/NEWS
+++ b/NEWS
@@ -1,22 +1,59 @@
-New in 1.13.2:
+* WARNING: New versioning scheme for Automake.
+
+  - Starting with this version onward, Automake will use an update and
+    more rational versioning scheme, one that will allow users to know
+    which kind of changes can be expected from a new version, based on
+    its version number.
+
+    + Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only
+      documentation updates and bug and regression fixes; they will
+      not introduce new features, nor any backward-incompatibility (any
+      such incompatibility would be considered a bug, to be fixed with
+      a further  micro release).
+
+    + Minor versions (e.g., 1.14, 2.1) can introduce new backward
+      compatible features; the only backward-incompatibilities allowed
+      in such a release are new *non-fatal* deprecations and warnings,
+      and possibly fixes for old or non-trivial bugs (or even inefficient
+      behaviours) that could unfortunately have been seen, and used, by
+      some developers as "corner case features".  This kind of fixes
+      should hopefully be quite rare.
+
+    + Major versions (now expected to be released every 18 or 24 months,
+      and not more often) can introduce new big features (possibly with
+      rough edges and not-fully-stabilized APIs), removal of deprecated
+      features, backward-incompatible changes of behaviour, and possibly
+      major refactorings (that, while ideally transparent to the user,
+      could introduce new bugs).  Incompatibilities should however not
+      be introduced gratuitously and abruptly; a proper deprecation path
+      should be duly implemented in the preceding minor releases.
+
+  - According to this new scheme, the next major version of Automake
+    (the one that has until now been labelled as '1.14') will actually
+    become "Automake 2.0".  Automake 1.14 will be the next minor version,
+    which will introduce new features and deprecation, but no backward
+    incompatibility.
+
+  - See discussion about automake bug#13578 for more details and
+    background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
 
 * WARNING: Future backward-incompatibilities!
 
-  - Automake 1.14 will require Autoconf 2.70 or later (which is still
+  - Automake 2.0 will require Autoconf 2.70 or later (which is still
     unreleased at the moment of writing, but is planned to be released
-    before Automake 1.14 is).
+    before Automake 2.0 is).
 
-  - Automake 1.14 will drop support for the long-deprecated 'configure.in'
+  - Automake 2.0 will drop support for the long-deprecated 'configure.in'
     name for the Autoconf input file.  You are advised to start using the
     recommended name 'configure.ac' instead, ASAP.
 
   - The ACLOCAL_AMFLAGS special make variable will be fully deprecated
-    in Automake 1.14 (where it will raise warnings in the "obsolete"
+    in Automake 2.0 (where it will raise warnings in the "obsolete"
     category).  You are advised to start relying on the new Automake
     support for AC_CONFIG_MACRO_DIRS instead (which was introduced in
     Automake 1.13).
 
-  - Automake 1.14 will remove support for automatic dependency tracking
+  - Automake 2.0 will remove support for automatic dependency tracking
     with the SGI C/C++ compilers on IRIX.  The SGI depmode has been
     reported broken "in the wild" already, and we don't think investing
     time in debugging and fixing is worthwhile, especially considering
@@ -30,16 +67,20 @@ New in 1.13.2:
     modern Windows versions will continue to be fully supported.
 
   - Automake-provided scripts and makefile recipes might (finally!)
-    start assuming a POSIX shell in Automake 1.14.
+    start assuming a POSIX shell in Automake 2.0.
 
-  - Starting from Automake 1.14, third-party m4 files located in the
+  - Starting from Automake 2.0, third-party m4 files located in the
     system-wide aclocal directory, as well as in any directory listed
     in the ACLOCAL_PATH environment variable, will take precedence
     over "built-in" Automake macros.  For example (assuming Automake
     is installed in the /usr/local hierarchy), a definition of the
     AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
     should take precedence over the same-named automake-provided macro
-    (defined in '/usr/local/share/aclocal-1.14/vala.m4').
+    (defined in '/usr/local/share/aclocal-2.0/vala.m4').
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.2:
 
 * Obsolescent features: