[PATCH] admin: automate one more part of the release process

View: New views
4 Messages — Rating Filter:   Alert me  

[PATCH] admin: automate one more part of the release process

by Jim Meyering :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

FYI, I've just pushed this to coreutils, so that the following
from README-release is no longer manual:

 * Manually set the date, version number, and [stable/alpha/beta] on
   line 3 of NEWS, then do e.g.,:

    v=8.0
    pkg=$(sed -n 's/^PACKAGE = \(.*\)/\1/p' Makefile)
    git commit -F <(printf 'version '$v'\n\n* NEWS: Record release date.\n') -a
    git tag -s -m "$pkg $v" v$v HEAD

The replacement is to do this:

  * Set the date, version number, and release type [stable/alpha/beta] on
    line 3 of NEWS, commit that, and tag the release by running e.g.,

    build-aux/do-release-commit-and-tag 8.1 beta

I'd been using a bash function similar to this new script for some time,
but now that I find myself making gzip, idutils, parted and coreutils
releases, it's past time to put it into version control and share.
I've committed it only to coreutils for now, but plan to move it to
gnulib very quickly.  So if you spot a problem or can suggest a better
name, please do;  I don't particularly like names that start with "do-",
but this isn't gnu-specific, so starting with gnu- seems less desirable.
My bash function was just called "do-release", but that was misleading,
since this is more like a pre-release step -- and easy to undo at that.



From 6eb457eaba841cc331d566a3f3dd83fc4cc5d058 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@...>
Date: Sat, 31 Oct 2009 11:08:03 +0100
Subject: [PATCH] admin: automate one more part of the release process

This script automates the process of updating NEWS, performs
the resulting final commit (thus with a consistent log message),
and applies a signed tag (v$VERSION) to the result.
* build-aux/do-release-commit-and-tag: New script.
* README-release: Document it.
---
 README-release                      |    9 +--
 build-aux/do-release-commit-and-tag |  138 +++++++++++++++++++++++++++++++++++
 2 files changed, 141 insertions(+), 6 deletions(-)
 create mode 100755 build-aux/do-release-commit-and-tag

diff --git a/README-release b/README-release
index e56c7a9..09b50d7 100644
--- a/README-release
+++ b/README-release
@@ -29,13 +29,10 @@ FIXME: enable excluded programs like arch? to get their manual pages?

 * Run "make distcheck"

-* Manually set the date, version number, and [stable/alpha/beta] on
-  line 3 of NEWS, then do e.g.,:
+* Set the date, version number, and release type [stable/alpha/beta] on
+  line 3 of NEWS, commit that, and tag the release by running e.g.,

-    v=8.0
-    pkg=$(sed -n 's/^PACKAGE = \(.*\)/\1/p' Makefile)
-    git commit -F <(printf 'version '$v'\n\n* NEWS: Record release date.\n') -a
-    git tag -s -m "$pkg $v" v$v HEAD
+    build-aux/do-release-commit-and-tag 8.1 beta

 * Run the following to create release tarballs.  Your choice selects the
   corresponding upload-to destination in the emitted gnupload command.
diff --git a/build-aux/do-release-commit-and-tag b/build-aux/do-release-commit-and-tag
new file mode 100755
index 0000000..8b9ad66
--- /dev/null
+++ b/build-aux/do-release-commit-and-tag
@@ -0,0 +1,138 @@
+#!/bin/sh
+# In a git/autoconf/automake-enabled project with a NEWS file and a version-
+# controlled .prev-version file, automate the procedure by which we record
+# the date, release-type and version string in the NEWS file.  That commit
+# will serve to identify the release, so apply a signed tag to it as well.
+VERSION=2009-10-31.09 # UTC
+
+# Note: this is a bash script (could be zsh or dash)
+
+# Copyright (C) 2009 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 3 of the License, 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 <http://www.gnu.org/licenses/>.
+
+# Written by Jim Meyering
+
+ME=`basename "$0"`
+warn() { printf '%s: %s\n' "$ME" "$*" >&2; }
+die() { warn "$*"; exit 1; }
+
+help_version()
+{
+  case $1 in
+    --help) cat <<EOF
+Usage: $ME VERSION RELEASE_TYPE
+
+Run this script to perform the final pre-release NEWS update
+in which the date, release-type and version string are recorded.
+Commit that result with a log entry marking the release, and apply
+a signed tag.  Run it from your project's the top-level directory.
+
+Requirements:
+- you use git for version-control
+- a NEWS file, with line 3 identical to this:
+* Noteworthy changes in release ?.? (????-??-??) [?]
+- a version-controlled .prev-version file
+
+Options:
+  --help     print this help, then exit
+  --version  print version number, then exit
+
+EXAMPLE:
+To update NEWS and tag the beta 8.1 release of coreutils, I would run this:
+
+  $ME 8.1 beta
+
+Report bugs and patches to <bug-gnulib@...>.
+EOF
+      exit ;;
+
+    --version)
+      year=`echo "$VERSION" | sed 's/[^0-9].*//'`
+      cat <<EOF
+$ME $VERSION
+Copyright (C) $year Free Software Foundation, Inc,
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+EOF
+      exit ;;
+
+  *) die "unrecognized option: $1";;
+  esac
+}
+
+case $# in
+  1) help_version $1; exit 0;;
+  2) ;;
+  *) warn "Usage: $ME VERSION TYPE"; exit 1;;
+esac
+
+ver=$1
+type=$2
+
+# Verify that $ver looks like a version number, and...
+echo "$ver"|grep -E '^[0-9][0-9.]*[0-9]$' > /dev/null \
+  || die "invalid version: $ver"
+prev_ver=$(cat .prev-version) \
+  || die 'failed to determine previous version number from .prev-version'
+
+# Verify that $ver is sensible (> .prev-version).
+case $(printf "$prev_ver\n$ver\n"|sort -V -u|tr '\n' ':') in
+  "$prev_ver:$ver:") ;;
+  *) die "invalid version: $ver";;
+esac
+
+case $type in
+  alpha|beta|stable) ;;
+  *) die "invalid release type: $type";;
+esac
+
+# Extract package name from Makefile.
+pkg=$(sed -n 's/^PACKAGE = \(.*\)/\1/p' Makefile) \
+  || die 'failed to determine package name from Makefile'
+
+# simple check: no question marks on line 3 of NEWS
+noteworthy='* Noteworthy changes in release'
+test "$(sed -n 3p NEWS)" = "$noteworthy ?.? (????-??-??) [?]" \
+  || die 'line 3 of NEWS looks fishy!'
+
+# No dirt allowed.
+case $(git diff-index --name-only HEAD) in
+  '') ;;
+  *) die 'this tree is dirty; commit your changes first';;
+esac
+
+# update NEWS to have today's date, plus desired version number and $type
+perl -MPOSIX -ni -e 'my $today = strftime "%F", localtime time;' \
+ -e 'my ($type, $ver) = qw('"$type $ver"');' \
+ -e 'my $pfx = "'"$noteworthy"'";' \
+ -e 'print $.==3 ? "$pfx $ver ($today) [$type]\n" : $_' \
+     NEWS || die 'failed to update NEWS'
+
+# Ensure the current branch name is "master":
+curr_br=$(git rev-parse --symbolic-full-name HEAD)
+test "$curr_br" = refs/heads/master || die not on master
+
+printf "version $ver\n\n* NEWS: Record release date.\n" \
+    | git commit -F -  -a || die 'git commit failed'
+git tag -s -m "$pkg $ver" v$ver HEAD || die 'git tag failed'
+
+# Local variables:
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "VERSION="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-time-zone: "UTC"
+# time-stamp-end: " # UTC"
+# End:
--
1.6.5.2.375.g164f1



Re: [PATCH] admin: automate one more part of the release process

by Jim Meyering :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jim Meyering wrote:

> FYI, I've just pushed this to coreutils, so that the following
> from README-release is no longer manual:
>
>  * Manually set the date, version number, and [stable/alpha/beta] on
>    line 3 of NEWS, then do e.g.,:
>
>     v=8.0
>     pkg=$(sed -n 's/^PACKAGE = \(.*\)/\1/p' Makefile)
>     git commit -F <(printf 'version '$v'\n\n* NEWS: Record release date.\n') -a
>     git tag -s -m "$pkg $v" v$v HEAD
>
> The replacement is to do this:
>
>   * Set the date, version number, and release type [stable/alpha/beta] on
>     line 3 of NEWS, commit that, and tag the release by running e.g.,
>
>     build-aux/do-release-commit-and-tag 8.1 beta
>
> I'd been using a bash function similar to this new script for some time,
> but now that I find myself making gzip, idutils, parted and coreutils
> releases, it's past time to put it into version control and share.
> I've committed it only to coreutils for now, but plan to move it to
> gnulib very quickly.  So if you spot a problem or can suggest a better
> name, please do;  I don't particularly like names that start with "do-",
> but this isn't gnu-specific, so starting with gnu- seems less desirable.
> My bash function was just called "do-release", but that was misleading,
> since this is more like a pre-release step -- and easy to undo at that.
...
> Subject: [PATCH] admin: automate one more part of the release process
>
> This script automates the process of updating NEWS, performs
> the resulting final commit (thus with a consistent log message),
> and applies a signed tag (v$VERSION) to the result.
> * build-aux/do-release-commit-and-tag: New script.
> * README-release: Document it.

No one objected, so I've moved it to gnulib as-is.
Here's what I've just pushed:

From 8c57bd68b7f28db2b7b7998b157b8dbb9e7e82a8 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@...>
Date: Fri, 6 Nov 2009 11:01:31 +0100
Subject: [PATCH] do-release-commit-and-tag: New module.

Automate the release-commit and tag process.
* build-aux/do-release-commit-and-tag: New script, from coreutils.
* modules/do-release-commit-and-tag: New file.
* MODULES.html.sh (Support for maintaining and releasing): Add it.
---
 ChangeLog                           |    8 ++
 MODULES.html.sh                     |    1 +
 build-aux/do-release-commit-and-tag |  139 +++++++++++++++++++++++++++++++++++
 modules/do-release-commit-and-tag   |   19 +++++
 4 files changed, 167 insertions(+), 0 deletions(-)
 create mode 100755 build-aux/do-release-commit-and-tag
 create mode 100644 modules/do-release-commit-and-tag

diff --git a/ChangeLog b/ChangeLog
index 73991dc..900a11a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2009-11-06  Jim Meyering  <meyering@...>
+
+ do-release-commit-and-tag: New module.
+ Automate the release-commit and tag process.
+ * build-aux/do-release-commit-and-tag: New script, from coreutils.
+ * modules/do-release-commit-and-tag: New file.
+ * MODULES.html.sh (Support for maintaining and releasing): Add it.
+
 2009-11-06  Simon Josefsson  <simon@...>

  * modules/select-tests (test_select_LDADD): Add $(INET_PTON_LIB)
diff --git a/MODULES.html.sh b/MODULES.html.sh
index cd8eef2..717e1ae 100755
--- a/MODULES.html.sh
+++ b/MODULES.html.sh
@@ -3212,6 +3212,7 @@ func_all_modules ()
   func_begin_table
   func_module announce-gen
   func_module autobuild
+  func_module do-release-commit-and-tag
   func_module git-version-gen
   func_module gitlog-to-changelog
   func_module gnu-web-doc-update
diff --git a/build-aux/do-release-commit-and-tag b/build-aux/do-release-commit-and-tag
new file mode 100755
index 0000000..ba0c1b2
--- /dev/null
+++ b/build-aux/do-release-commit-and-tag
@@ -0,0 +1,139 @@
+#!/bin/sh
+# In a git/autoconf/automake-enabled project with a NEWS file and a version-
+# controlled .prev-version file, automate the procedure by which we record
+# the date, release-type and version string in the NEWS file.  That commit
+# will serve to identify the release, so apply a signed tag to it as well.
+VERSION=2009-11-06.10 # UTC
+
+# Note: this is a bash script (could be zsh or dash)
+
+# Copyright (C) 2009 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 3 of the License, 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 <http://www.gnu.org/licenses/>.
+
+# Written by Jim Meyering
+
+ME=`basename "$0"`
+warn() { printf '%s: %s\n' "$ME" "$*" >&2; }
+die() { warn "$*"; exit 1; }
+
+help_version()
+{
+  case $1 in
+    --help) cat <<EOF
+Usage: $ME VERSION RELEASE_TYPE
+
+Run this script to perform the final pre-release NEWS update
+in which the date, release-type and version string are recorded.
+Commit that result with a log entry marking the release, and apply
+a signed tag.  Run it from your project's the top-level directory.
+
+Requirements:
+- you use git for version-control
+- a NEWS file, with line 3 identical to this:
+* Noteworthy changes in release ?.? (????-??-??) [?]
+- a version-controlled .prev-version file
+
+Options:
+  --help     print this help, then exit
+  --version  print version number, then exit
+
+EXAMPLE:
+To update NEWS and tag the beta 8.1 release of coreutils, I would run this:
+
+  $ME 8.1 beta
+
+Report bugs and patches to <bug-gnulib@...>.
+EOF
+      exit ;;
+
+    --version)
+      year=`echo "$VERSION" | sed 's/[^0-9].*//'`
+      cat <<EOF
+$ME $VERSION
+Copyright (C) $year Free Software Foundation, Inc,
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+EOF
+      exit ;;
+
+  *) die "unrecognized option: $1";;
+  esac
+}
+
+case $# in
+  1) help_version $1; exit 0;;
+  2) ;;
+  *) warn "Usage: $ME VERSION TYPE"; exit 1;;
+esac
+
+ver=$1
+type=$2
+
+# Verify that $ver looks like a version number, and...
+echo "$ver"|grep -E '^[0-9][0-9.]*[0-9]$' > /dev/null \
+  || die "invalid version: $ver"
+prev_ver=$(cat .prev-version) \
+  || die 'failed to determine previous version number from .prev-version'
+
+# Verify that $ver is sensible (> .prev-version).
+case $(printf "$prev_ver\n$ver\n"|sort -V -u|tr '\n' ':') in
+  "$prev_ver:$ver:") ;;
+  *) die "invalid version: $ver";;
+esac
+
+case $type in
+  alpha|beta|stable) ;;
+  *) die "invalid release type: $type";;
+esac
+
+# Extract package name from Makefile.
+pkg=$(sed -n 's/^PACKAGE = \(.*\)/\1/p' Makefile) \
+  || die 'failed to determine package name from Makefile'
+
+# simple check: no question marks on line 3 of NEWS
+noteworthy='* Noteworthy changes in release'
+test "$(sed -n 3p NEWS)" = "$noteworthy ?.? (????-??-??) [?]" \
+  || die 'line 3 of NEWS looks fishy!'
+
+# No dirt allowed.
+case $(git diff-index --name-only HEAD) in
+  '') ;;
+  *) die 'this tree is dirty; commit your changes first';;
+esac
+
+# update NEWS to have today's date, plus desired version number and $type
+perl -MPOSIX -ni -e 'my $today = strftime "%F", localtime time;' \
+ -e 'my ($type, $ver) = qw('"$type $ver"');' \
+ -e 'my $pfx = "'"$noteworthy"'";' \
+ -e 'print $.==3 ? "$pfx $ver ($today) [$type]\n" : $_' \
+     NEWS || die 'failed to update NEWS'
+
+# Ensure the current branch name is "master":
+curr_br=$(git rev-parse --symbolic-full-name HEAD)
+test "$curr_br" = refs/heads/master || die not on master
+
+printf "version $ver\n\n* NEWS: Record release date.\n" \
+    | git commit -F -  -a || die 'git commit failed'
+git tag -s -m "$pkg $ver" v$ver HEAD || die 'git tag failed'
+
+# Local variables:
+# indent-tabs-mode: nil
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "VERSION="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-time-zone: "UTC"
+# time-stamp-end: " # UTC"
+# End:
diff --git a/modules/do-release-commit-and-tag b/modules/do-release-commit-and-tag
new file mode 100644
index 0000000..e2f80a5
--- /dev/null
+++ b/modules/do-release-commit-and-tag
@@ -0,0 +1,19 @@
+Description:
+Automate the release-commit and tag process.
+
+Files:
+build-aux/do-release-commit-and-tag
+
+Depends-on:
+
+configure.ac:
+
+Makefile.am:
+
+Include:
+
+License:
+GPLed build tool
+
+Maintainer:
+coreutils
--
1.6.5.2.303.g13162



Re: [PATCH] admin: automate one more part of the release process

by Thiago Farina-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Jim,

On Fri, Nov 6, 2009 at 8:17 AM, Jim Meyering <jim@...> wrote:

> Jim Meyering wrote:
>> FYI, I've just pushed this to coreutils, so that the following
>> from README-release is no longer manual:
>>
>>  * Manually set the date, version number, and [stable/alpha/beta] on
>>    line 3 of NEWS, then do e.g.,:
>>
>>     v=8.0
>>     pkg=$(sed -n 's/^PACKAGE = \(.*\)/\1/p' Makefile)
>>     git commit -F <(printf 'version '$v'\n\n* NEWS: Record release date.\n') -a
>>     git tag -s -m "$pkg $v" v$v HEAD
>>
>> The replacement is to do this:
>>
>>   * Set the date, version number, and release type [stable/alpha/beta] on
>>     line 3 of NEWS, commit that, and tag the release by running e.g.,
>>
>>     build-aux/do-release-commit-and-tag 8.1 beta
> No one objected, so I've moved it to gnulib as-is.

I noticed that there is a build-aux in coreutils tree, but since there
is no do-release-commit-and-tag in there, I think it could be like
this:

diff --git a/README-release b/README-release
index 09b50d7..6d8b824 100644
--- a/README-release
+++ b/README-release
@@ -32,7 +32,7 @@ FIXME: enable excluded programs like arch? to get
their manual pages?
 * Set the date, version number, and release type [stable/alpha/beta] on
   line 3 of NEWS, commit that, and tag the release by running e.g.,

-    build-aux/do-release-commit-and-tag 8.1 beta
+    gnulib/build-aux/do-release-commit-and-tag 8.1 beta

 * Run the following to create release tarballs.  Your choice selects the
   corresponding upload-to destination in the emitted gnupload command.



Re: [PATCH] admin: automate one more part of the release process

by Jim Meyering :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thiago Farina wrote:
...
>>>     build-aux/do-release-commit-and-tag 8.1 beta
>> No one objected, so I've moved it to gnulib as-is.
>
> I noticed that there is a build-aux in coreutils tree, but since there
> is no do-release-commit-and-tag in there, I think it could be like
> this:
>
> diff --git a/README-release b/README-release
...
> -    build-aux/do-release-commit-and-tag 8.1 beta
> +    gnulib/build-aux/do-release-commit-and-tag 8.1 beta

Thanks, but that's not needed.
If you run (or re-run) ./bootstrap, it will copy
the script into build-aux/.