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 <a...@lrde.epita.fr> > 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 <a...@lrde.epita.fr> > 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 <a...@lrde.epita.fr> > + > + 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 <a...@lrde.epita.fr> > > 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 <a...@lrde.epita.fr> > 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.
