maint: more adjustments to the new versioning scheme

This is a follow-up to commit 'v1.13.1b-11-g97aaf12'.

* automake.in: Adjust a comment.
* PLANS: Adjust several files in here.

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

5 files changed, 21 insertions, 23 deletions

diff --git a/PLANS/obsolete-removed/am-prog-mkdir-p.txt b/PLANS/obsolete-removed/am-prog-mkdir-p.txt
index d5b769553..20d5cf52c 100644
--- a/PLANS/obsolete-removed/am-prog-mkdir-p.txt
+++ b/PLANS/obsolete-removed/am-prog-mkdir-p.txt
@@ -1,6 +1,4 @@
-The macro AM_PROG_MKDIR_P is no longer going to be removed in Automake 1.14
-(and in fact, any plan to remove it "evenatually" has been dropped as well).
-
+The macro AM_PROG_MKDIR_P is no longer going to be removed from Automake.
 Let's see a bit of history to understand why.
 
 I had already scheduled the removal of the long-deprecated AM_PROG_MKDR_P
@@ -46,14 +44,14 @@ out, and we lose.  That already happened in practice:
     <http://lists.gnu.org/archive/html/bug-grep/2013-01/msg00003.html>
 
 Moreover, while I might see it as not unreasonable to ask a developer
-using Automake 1.14 to also update Gettext to 1.18.2, that would not
+using Automake 2.0 to also update Gettext to 1.18.2, that would not
 be enough; in order for gettext to use the correct data files, that
 developer would have to update his configure.ac to read:
 
     AM_GNU_GETTEXT_VERSION([0.18.2])
 
 thus requiring *all* of his co-developers to install Gettext 1.18.2,
-even if they are still using, say, Automake 1.13.  Bad.
+even if they are still using, say, Automake 1.13 or 1.14.  Bad.
 
 So I decided to re-instate this macro as a simple alias for AC_PROG_MKDIR_P
 (plus a non-fatal runtime warning in the 'obsolete' category), and drop
diff --git a/PLANS/obsolete-removed/configure.in.txt b/PLANS/obsolete-removed/configure.in.txt
index baed853bc..180f92c14 100644
--- a/PLANS/obsolete-removed/configure.in.txt
+++ b/PLANS/obsolete-removed/configure.in.txt
@@ -13,16 +13,16 @@ present in the development version of autoconf so far (scheduled to
 become Autoconf 2.70).  So ...
 
 
-For Automake 1.14
------------------
+For Automake 2.0
+----------------
 
 ... we have decided to wait until 2.70 is out before really removing
 'configure.in' support.  Since we plan to require Autoconf 2.70 in
-Automake 1.14 (so that we can remove the hacky code emulating
+Automake 2.0 (so that we can remove the hacky code emulating
 AC_CONFIG_MACRO_DIRS for older autoconf versions), we are quite sure
 that Autoconf will actually have started deprecating 'configure.in'
-by the time Automake 1.14 is released.
+by the time Automake 2.0 is released.
 
 Note that the removal of 'configure.in' has already been implemented
-in our master branch (from where the 1.14 release will be finally
+in our 'next' branch (from where the 2.0 release will be finally
 cut); see commits 'v1.13-17-gbff57c8' and 'v1.13-21-g7626e63'.
diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt
index 5362f98e6..918e0492d 100644
--- a/PLANS/rm-f-without-args.txt
+++ b/PLANS/rm-f-without-args.txt
@@ -21,20 +21,20 @@ the no-args "rm -f" usage is supported on the system configure is
 being run on; complain loudly if this is not the case, and tell the
 user to report the situation to us.
 
-For Automake 1.14
------------------
+For Automake 2.0
+----------------
 
 Make any failure in the configure-time probe check introduced by the
 previous point fatal; and in case of failure, also suggest to the user
 to install an older version of GNU coreutils to work around the
 limitation of his system (this version should be old enough not to
-be bootstrapped with Automake 1.14, otherwise the user will face a
+be bootstrapped with Automake 2.0, otherwise the user will face a
 bootstrapping catch-22).
 
 In all our recipes, start assuming "rm -f" with no argument is OK;
 simplify and de-uglify the recipes accordingly.
 
-For Automake 1.15
------------------
+For Automake 3.0
+----------------
 
 Remove the runtime probe altogether.
diff --git a/PLANS/subdir-objects.txt b/PLANS/subdir-objects.txt
index e4e6e25ad..86474036a 100644
--- a/PLANS/subdir-objects.txt
+++ b/PLANS/subdir-objects.txt
@@ -2,7 +2,7 @@ Summary
 -------
 
 We want to make the behaviour currently enabled by the 'subdir-objects'
-the default one, and in fact the *only* one, in Automake 1.14.
+the default one, and in fact the *only* one, in Automake 2.0.
 See automake bug#13378: <http://debbugs.gnu.org/13351>.
 
 Details
@@ -38,8 +38,8 @@ C compilation rules mistakenly passed the "-c -o" options combination
 unconditionally (even to losing compiler) when the 'subdir-objects' was
 used but sources were only present in the top-level directory.
 
-TODO for automake 1.13.2
-------------------------
+TODO for automake 1.14
+----------------------
 
 Give a warning in the category 'unsupported' if the 'subdir-objects'
 option is not specified.  This should give the users enough forewarning
@@ -50,8 +50,8 @@ Be sure to avoid the warning when it would be irrelevant, i.e., if all
 source files sit in "current" directory (thanks to Peter Johansson for
 suggesting this).
 
-For automake 1.14
------------------
+For automake 2.0
+----------------
 
 Remove the copy & paste of Autoconf internals in our AC_PROG_CC rewrite
 See the first patch in the series:
diff --git a/PLANS/texi/drop-split-info-files.txt b/PLANS/texi/drop-split-info-files.txt
index 708433158..8b36ecb05 100644
--- a/PLANS/texi/drop-split-info-files.txt
+++ b/PLANS/texi/drop-split-info-files.txt
@@ -1,7 +1,7 @@
-For automake 1.14
------------------
+For automake 2.0
+----------------
 
-We want to drop split info files in Automake 1.14.
+We want to drop split info files in Automake 2.0.
 See automake bug#13351: <http://debbugs.gnu.org/13351>.
 
 Basically, it has been confirmed that the original reason behind