From: Karl Berry Date: Tue, 27 May 2025 16:01:00 +0000 (-0700) Subject: maint: 1.18 released, version now 1.18.0.91. X-Git-Tag: v1.18.1~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9639fc23ae201ec7e2fb8009ac442ef1fe47f431;p=thirdparty%2Fautomake.git maint: 1.18 released, version now 1.18.0.91. * configure.ac (AC_INIT): now 1.18.0.91. * m4/amversion.m4 (AM_AUTOMAKE_VERSION): 1.18.0.91 (auto-update). * HACKING: release tweaks. --- diff --git a/HACKING b/HACKING index 61ddc3a99..0f5263f2f 100644 --- a/HACKING +++ b/HACKING @@ -540,11 +540,12 @@ * Update the AC_INIT version number in configure.ac. Leading up to a minor release (x.y), say 1.17, pretests should be numbered from - 1.16.90. Even numbers (1.16.90, 1.16.92, ...) should be pretest - releases; odd numbers (1.16.91, 1.16.93, ...) should be only - development versions. Leading up to a micro release (x.y.z), say - 1.17.1, we would have 1.17.0.91 for the initial post-release - development version, 1.17.0.92 for the first pretest, etc. + 1.16.92. Odd numbers (1.16.91, 1.16.93, ...) should be for + between-release development versions, and even numbers (1.16.92, + 1.16.92, ...) should be pretest releases. Leading up to a micro + release (x.y.z), say 1.17.1, we would have 1.17.0.91 for the initial + post-release development version, 1.17.0.92 for the first pretest, + etc. Before 1.17 (July 2024), we used suffixed letters for pretests, as is traditional, but deficient sorting algorithms did not like that. The @@ -566,7 +567,7 @@ don't worry about every detail, because the below invocation of announce-gen will create another announcement to be merged with this. -* Run these commands, in this order (as mentioned, adjust -j as desired): +* Run these commands, in this order (adjust -j as desired as usual): make bootstrap make -j12 check keep_testdirs=yes make maintainer-check @@ -575,8 +576,6 @@ make -j12 distcheck # regular distcheck make -j12 distcheck AM_TESTSUITE_MAKE="make -j12" # parallelize makes - The resulting automake-$VERSION.tar.* files are what will be the release. - You can run "git clean -fdx" before invoking the bootstrap, to ensure a completely clean rebuild. However, it must be done carefully, because that command will remove *all* the files that are not tracked @@ -594,8 +593,8 @@ locally because you ran it too soon: git tag --delete v$VERSION.) * Create additional info for the announcement with the announce-gen - script that is part of gnulib. It requires the new release tarball, - and the already-tagged repository. + script that is part of gnulib. It requires the release tarball made + above, and the repository to be tagged with the new release tag. pkg=automake prever=1.16 # 1.17 newver=1.16.94 # 1.18 @@ -617,17 +616,22 @@ This will first verify that you are releasing from a tagged version and that the local git repository and working tree are clean and - up-to-date, and will then run "make dist" to create the tarballs, - and invoke the 'gnupload' script sign and upload them to the correct - locations. + up-to-date. Then it will run "make dist" to create the release + tarballs (again, so hopefully no changes have been made in the + meantime), and invoke the 'gnupload' script sign and upload them to + the correct locations. If you need to sign with a non-default key, you can use "make GNUPLOADFLAGS='--user KEY' git-upload-release". There can be a delay of up to several minutes before the new files appear on the server. +* Push the new release tag: git push origin master tag v$(VERSION). + You can view unpushed local-only tags with git push --tags --dry-run + (and push them by omitting the --dry-run, if there are no extras). + * For stable releases you also need to update the manuals on www.gnu.org. - - Check links: + - Check links (except do this before the release): make html make checklinkx # various perl prerequisites, see contrib/checklinkx or use: @@ -648,10 +652,10 @@ for example: make web-manual-update CVS_USER=slattarini -* Update version number in configure.ac to next alpha number. - Rerun ./bootstrap and commit and push. +* Update version number in configure.ac to development version number + (see above). Rerun ./bootstrap and commit and push. -* Send the announcement generated in the earlier steps at least to +* Send the announcement created in the earlier steps at least to and . If the release is a stable one, the announcement also goes to ; if it is an alpha or beta release, announcement should be sent also diff --git a/configure.ac b/configure.ac index f6acfad75..76d743def 100644 --- a/configure.ac +++ b/configure.ac @@ -16,7 +16,7 @@ # along with this program. If not, see . AC_PREREQ([2.69]) -AC_INIT([GNU Automake], [1.18], [bug-automake@gnu.org]) +AC_INIT([GNU Automake], [1.18.0.91], [bug-automake@gnu.org]) AC_CONFIG_SRCDIR([bin/automake.in]) AC_CONFIG_AUX_DIR([lib]) diff --git a/m4/amversion.m4 b/m4/amversion.m4 index ddee6d621..c10af72c6 100644 --- a/m4/amversion.m4 +++ b/m4/amversion.m4 @@ -15,7 +15,7 @@ AC_DEFUN([AM_AUTOMAKE_VERSION], [am__api_version='1.18' dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to dnl require some minimum version. Point them to the right macro. -m4_if([$1], [1.18], [], +m4_if([$1], [1.18.0.91], [], [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl ]) @@ -31,7 +31,7 @@ m4_define([_AM_AUTOCONF_VERSION], []) # Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced. # This function is AC_REQUIREd by AM_INIT_AUTOMAKE. AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION], -[AM_AUTOMAKE_VERSION([1.18])dnl +[AM_AUTOMAKE_VERSION([1.18.0.91])dnl m4_ifndef([AC_AUTOCONF_VERSION], [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])