[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: maint.mk: improve the release procedure
From: |
Jim Meyering |
Subject: |
Re: maint.mk: improve the release procedure |
Date: |
Fri, 21 Sep 2012 16:44:34 +0200 |
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.
- Re: maint.mk: improve the release procedure, Akim Demaille, 2012/09/21
- Re: maint.mk: improve the release procedure,
Jim Meyering <=
- Re: maint.mk: improve the release procedure, Akim Demaille, 2012/09/22
- Re: maint.mk: improve the release procedure, Jim Meyering, 2012/09/22
- Re: maint.mk: improve the release procedure, Akim Demaille, 2012/09/23
- Re: maint.mk: improve the release procedure, Jim Meyering, 2012/09/23
- Re: maint.mk: improve the release procedure, Akim Demaille, 2012/09/24
- Re: maint.mk: improve the release procedure, Jim Meyering, 2012/09/24
- Re: maint.mk: improve the release procedure, Akim Demaille, 2012/09/24
- Re: maint.mk: improve the release procedure, Jim Meyering, 2012/09/25
- Re: maint.mk: improve the release procedure, Akim Demaille, 2012/09/25
- Re: maint.mk: improve the release procedure, Akim Demaille, 2012/09/25