doc: move future 2.0 incompatibilities to separate file.

* NEWS: move info to ...
* NEWS-2.0: ... this new file.
* Makefile.am (EXTRA_DIST): add it.

3 files changed, 101 insertions, 62 deletions

diff --git a/Makefile.am b/Makefile.am
index d8a9da1b5..1a5445d93 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -36,6 +36,7 @@ EXTRA_DIST += \
   bootstrap \
   GNUmakefile \
   HACKING \
+  NEWS-2.0 \
   PLANS
 
 # We want a handful of substitutions to be fully-expanded by make;
diff --git a/NEWS b/NEWS
index aee9f4eb6..5e92387e2 100644
--- a/NEWS
+++ b/NEWS
@@ -1,64 +1,5 @@
-* WARNING: Future backward-incompatibilities!
-
-  - Makefile recipes generated by Automake 2.0 will expect to use an
-    'rm' program that doesn't complain when called without any non-option
-    argument if the '-f' option is given (so that commands like "rm -f"
-    and "rm -rf" will act as a no-op, instead of raising usage errors).
-    This behavior of 'rm' is very widespread in the wild, and it will be
-    required in the next POSIX version:
-
-      <http://austingroupbugs.net/view.php?id=542>
-
-    Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
-    that the default 'rm' program in PATH satisfies this requirement,
-    aborting the configure process if this is not the case.  For the
-    moment, it's still possible to force the configuration process to
-    succeed even with a broken 'rm', that that will no longer be the case
-    for Automake 2.0.
-
-  - 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 2.0 is).
-
-  - 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 2.0: it will raise warnings in the "obsolete" category (but
-    still no hard error of course, for compatibilities with the many, many
-    packages that still relies on that variable).  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 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
-    that SGI has last updated those compilers in 2006, and retired
-    support for them in December 2013:
-    <http://www.sgi.com/services/support/irix_mips_support.html>
-
-  - Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME
-    (support for them was offered by relying on the DJGPP project).
-    Note however that both Cygwin and MSYS/MinGW on modern Windows
-    versions will continue to be fully supported.
-
-  - Automake-provided scripts and makefile recipes might (finally!)
-    start assuming a POSIX shell in Automake 2.0.  There still is no
-    certainty about this though: we'd first like to wait and see
-    whether future Autoconf versions will be enhanced to guarantee
-    that such a shell is always found and provided by the checks in
-    ./configure.
-
-  - 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-2.0/vala.m4').
+For planned incompatibilities in a future Automake 2.0 release,
+please see NEWS-2.0 and start following the advice there now.
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -3126,7 +3067,7 @@ New in 0.20:
 
 -----
 
-Copyright (C) 1995-2020 Free Software Foundation, Inc.
+Copyright (C) 1995-2021 Free Software Foundation, Inc.
 
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
diff --git a/NEWS-2.0 b/NEWS-2.0
new file mode 100644
index 000000000..743138ca9
--- /dev/null
+++ b/NEWS-2.0
@@ -0,0 +1,97 @@
+This file (NEWS-2.0) lists several incompatibilities planned for a
+future Automake 2.0 release.
+
+However, the (few) current Automake maintainers have insufficient interest
+and energy to pursue the 2.0 release.  We have not even reviewed all
+existing bugs.  New maintainers are needed!  For more information about
+helping with Automake development:
+https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html
+
+Therefore, there is no ETA for Automake 2.0, but it is not likely to be
+any time soon.  So moving these future issues to a separate file seemed
+warranted.  For more info, see the ./PLANS/ directory.
+
+
+* WARNING: Future backward-incompatibilities!
+
+  - Makefile recipes generated by Automake 2.0 will expect to use an
+    'rm' program that doesn't complain when called without any non-option
+    argument if the '-f' option is given (so that commands like "rm -f"
+    and "rm -rf" will act as a no-op, instead of raising usage errors).
+    This behavior of 'rm' is very widespread in the wild, and it will be
+    required in the next POSIX version:
+
+      <http://austingroupbugs.net/view.php?id=542>
+
+    Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
+    that the default 'rm' program in PATH satisfies this requirement,
+    aborting the configure process if this is not the case.  For the
+    moment, it's still possible to force the configuration process to
+    succeed even with a broken 'rm', but that will no longer be the case
+    for Automake 2.0.
+
+  - Automake 2.0 will require Autoconf 2.71 or later.  Exact
+    dependencies are unknowable at ths time.
+
+  - 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 2.0: it will raise warnings in the "obsolete" category (but
+    still no hard error of course, for compatibilities with the many, many
+    packages that still relies on that variable).  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 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
+    that SGI has last updated those compilers in 2006, and retired
+    support for them in December 2013:
+    <http://www.sgi.com/services/support/irix_mips_support.html>
+
+  - Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME
+    (support for them was offered by relying on the DJGPP project).
+    Note however that both Cygwin and MSYS/MinGW on modern Windows
+    versions will continue to be fully supported.
+
+  - Automake-provided scripts and makefile recipes might (finally!)
+    start assuming a POSIX shell in Automake 2.0.  There still is no
+    certainty about this though: we'd first like to wait and see
+    whether future Autoconf versions will be enhanced to guarantee
+    that such a shell is always found and provided by the checks in
+    ./configure. 
+    
+    In 2020, config.guess was changed by its then-maintainer to require
+    $(...); the ensuing bug reports and maintenance hassle
+    (unfortunately the changes have not been reverted) are a convincing
+    argument that we should not require a POSIX shell until Solaris 10,
+    at least, is completely gone from the world.
+
+  - 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-2.0/vala.m4').
+
+-----
+
+Copyright (C) 1995-2021 Free Software Foundation, Inc.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program.  If not, see <https://www.gnu.org/licenses/>.