Re: maint.mk: improve the release procedure

[Jim Meyering]

Akim Demaille wrote:
> Le 3 août 2012 à 11:41, Jim Meyering a écrit :
>
>> Akim Demaille wrote:
>>> There is still the uploading step which is not bound to a make
>>> target.  I would remove the emit_upload_command completely, and
>>> instead mention the upload target in README-release, including the
>>> announcement step, WDYT?
>>
>> Hi Akim,
>>
>> I like the added automation.  Thanks.
>> ACK to your amended patch.
>>
>> However, we should not remove the emit_upload_command rule because
>> even without multiple upload target URLs, it is nontrivial.
>> I want to be able to mouse it, if necessary, not type it from scratch
>> when the new make rule happens to no longer work.
>>
>> When might that be?
>>
>> Well, once you've run "make stable" to create the tarball, you've made the
>> first commit after the tag: i.e., the "maint: post-release administrivia".
>> For now that's fine, because the VERSION variable in Makefile is still
>> at the bare release number (say "1.0"), rather than what git-describe
>> would print: v1.0-1-gHHHHHHH.  Currently, GNUmakefile deliberately defers
>> the update of VERSION, so this is fine.  Unless you happen to run "make
>> _version" (or e.g., make dist) before you run the new "make upload".
>> Those would update VERSION to v1.0-1-gHHHHHHH.  Once that happens, your
>> "make upload" command will try to upload not the release you intend,
>> but the v1.0-1-gHHHHHHH.tar.xz tarball.  Oops.
>>
>> Hence, the emit_upload_command output serves as a record of the desired
>> upload command that can be used more reliably than "make upload".
>>
>> --------------
>> Hmm... maybe I need to retract that ACK.
>> Providing this new "make upload" target may make it too easy to
>> accidentally upload as "stable" a version like v1.0-44-gHHHHHHH.
>>
>> If you add a safety net that rejects (or at least warns otherwise,
>> and requires some sort of manual override) a "stable" VERSION that
>> matches /-\d+-g/, I would be more comfortable.
>
> hi Jim,

Hi Akim!

> I'm finally back on this issue.  I suggest the following three patches
> to address this issue.  Actually the first two are just cleanups, and
> only the last one addresses the issue.  In order to both improve reliability
> and consistency between the different targets, I promote RELEASE='X.Y TYPE'
> as recurring user input for them.
>
> From 9fc32589802eb9369138cf244c446cdcf8f6e491 Mon Sep 17 00:00:00 2001
> From: Akim Demaille <address@hidden>
> Date: Thu, 20 Sep 2012 11:09:53 +0200
> Subject: [PATCH 1/3] maint.mk: silent rules
>
> With help from Stefano Lattarini.
...

Thanks!  I'd noticed that stray line at the top of announcement
templates and had just deleted it manually.

> From 3547cd4888812a54bae45ffa2dbabdb08e59b874 Mon Sep 17 00:00:00 2001
> From: Akim Demaille <address@hidden>
> Date: Fri, 21 Sep 2012 14:11:18 +0200
> Subject: [PATCH 2/3] maint.mk: factor the validation of RELEASE_TYPE
>
> * top/maint.mk (GET_RELEASE_TYPE): New.
> Use it instead of $(RELEASE_TYPE).
> Remove now useless local checks.
> ---
>  ChangeLog    |  7 +++++++
>  top/maint.mk | 19 +++++++++++++------
>  2 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index b1856eb..61a40a2 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,10 @@
> +2012-09-21  Akim Demaille  <address@hidden>
> +
> +     maint.mk: factor the validation of RELEASE_TYPE
> +     * top/maint.mk (GET_RELEASE_TYPE): New.
> +     Use it instead of $(RELEASE_TYPE).
> +     Remove now useless local checks.
> +
>  2012-09-20  Akim Demaille  <address@hidden>
>
>       maint.mk: silent rules
> diff --git a/top/maint.mk b/top/maint.mk
> index 87bbde9..e8ea768 100644
> --- a/top/maint.mk
> +++ b/top/maint.mk
> @@ -91,13 +91,22 @@ my_distdir = $(PACKAGE)-$(VERSION)
>  # Old releases are stored here.
>  release_archive_dir ?= ../release
>
> +# Validate and return $(RELEASE_TYPE), or die.
> +GET_RELEASE_TYPE =                                              \
> +  $(if $(RELEASE_TYPE),                                         \
> +    $(or $(shell case '$(RELEASE_TYPE)' in                      \
> +                   (alpha|beta|stable) echo $(RELEASE_TYPE);;   \
> +                 esac),                                         \
> +       $(error invalid RELEASE_TYPE: $(RELEASE_TYPE))),         \
> +    $(error RELEASE_TYPE undefined))

This looks like a fine improvement.
However, can't you do it without the cost of a $(shell ...)?
How about using $(findstring ...) instead?
Would be nice, but not required.

> From 52cfcc3a334abd7e4b028bb502761e9a3281f7b9 Mon Sep 17 00:00:00 2001
> From: Akim Demaille <address@hidden>
> Date: Thu, 20 Sep 2012 11:10:34 +0200
> Subject: [PATCH 3/3] maint.mk: provide "make upload" to ease uploading
>
> See <http://lists.gnu.org/archive/html/bug-gnulib/2012-08/msg00028.html>.
> Do not depend simply on the current $(VERSION), as there may have been
> new commits since the tarball generation.  Rather, rely on $(RELEASE),
> as "make release-commit" already does.
>
> For consistency, add "make release RELEASE='X.Y TYPE'" as an alias for
> "make TYPE".
>
> * top/maint.mk (upload_command, upload, release): New.
> (RELEASE_TYPE): If undefined, default to the second word of $(RELEASE).
> (VERSION): first word of $(RELEASE) is always right.
> (emit_upload_commands): Adjust.
> * top/README-release: Update.

This seems to mean that one will always have to specify RELEASE, even with
"make upload"?  How about using the contents of .prev-version instead
of requiring that?  Oh... that is the VERSION part.  It looks like the
RELEASE_TYPE is not saved anywhere.  So what I want (making "make upload"
use saved state) is a bigger job, and a task for a separate commit.

ACK to all three.
Thanks again.