[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, an
From: |
Stefano Lattarini |
Subject: |
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository |
Date: |
Thu, 21 Feb 2013 16:06:43 +0100 |
On 02/21/2013 03:32 PM, Stefano Lattarini wrote:
>> Not yet; we first need a preparatory patch adjusting NEWS and HACKING (as
>> well as few miscellaneous comments in tests and scripts). Then we can
>> finally proceed with the re-shuffling of the Git repository -- which I
>> guess will also have to be announced in autotools-announce at least, as
>> well as reported as a news on Savannah.
>>
>> So here is my attempt; OK to push to branch-1.13.2? I will proceed in a
>> couple of days if there is no objection.
>>
> Pushed now.
>
And here is the follow-up to fix some left-over references to the older
versioning scheme in 'maint' (they were not present in 'branch-1.13.2').
Already pushed to 'maint'.
In a couple of days, I will proceed with this "branch moving":
* branch-1.13.2 -> maint
* maint -> master
* master -> next
Regards,
Stefano
---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----
>From d5f83b89cc4d2da9078669018877b3bac5c2fadc Mon Sep 17 00:00:00 2001
Message-Id: <address@hidden>
From: Stefano Lattarini <address@hidden>
Date: Thu, 21 Feb 2013 15:52:22 +0100
Subject: [PATCH] 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 <address@hidden>
---
PLANS/obsolete-removed/am-prog-mkdir-p.txt | 8 +++-----
PLANS/obsolete-removed/configure.in.txt | 10 +++++-----
PLANS/rm-f-without-args.txt | 10 +++++-----
PLANS/subdir-objects.txt | 10 +++++-----
PLANS/texi/drop-split-info-files.txt | 6 +++---
automake.in | 2 +-
6 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/PLANS/obsolete-removed/am-prog-mkdir-p.txt
b/PLANS/obsolete-removed/am-prog-mkdir-p.txt
index d5b7695..20d5cf5 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 baed853..180f92c 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 5362f98..918e049 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 e4e6e25..8647403 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 7084331..8b36ecb 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
diff --git a/automake.in b/automake.in
index 44d67b4..13811f7 100644
--- a/automake.in
+++ b/automake.in
@@ -1711,7 +1711,7 @@ sub handle_single_transform ($$$$$%)
}
else
{
- # Since the next major version of automake (1.14) will
+ # Since the next major version of automake (2.0) will
# make the behaviour so far only activated with the
# 'subdir-object' option mandatory, it's better if we
# start warning users not using that option.
--
1.8.1.1.754.gb3600c3
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, (continued)
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Miles Bader, 2013/02/11
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Stefano Lattarini, 2013/02/12
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Miles Bader, 2013/02/12
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Stefano Lattarini, 2013/02/12
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Miles Bader, 2013/02/12
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Vincent Torri, 2013/02/12
bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Stefano Lattarini, 2013/02/13
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Stefano Lattarini, 2013/02/17
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository, Stefano Lattarini, 2013/02/21
- bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository,
Stefano Lattarini <=
- bug#13578: [IMPORTANT] *Implemented* a new versioning scheme for automake releases, and a new branching scheme for the Git repository, Stefano Lattarini, 2013/02/23
- bug#13578: [IMPORTANT] Savannah issues, Stefano Lattarini, 2013/02/23
- bug#13578: [IMPORTANT] Savannah issues, Peter Rosin, 2013/02/25
- bug#13578: [IMPORTANT] Savannah issues, Stefano Lattarini, 2013/02/25
- bug#13578: [IMPORTANT] Savannah issues, Peter Rosin, 2013/02/25
- bug#13578: [IMPORTANT] Savannah issues, Stefano Lattarini, 2013/02/26
- bug#13578: [IMPORTANT] Savannah issues, Miles Bader, 2013/02/26
- bug#13578: [IMPORTANT] Savannah issues, Stefano Lattarini, 2013/02/27
- bug#13578: [IMPORTANT] Savannah issues, Miles Bader, 2013/02/26
- bug#13578: [IMPORTANT] Savannah issues, Stefano Lattarini, 2013/02/27