Re: maint.mk: improve the release procedure

[Jim Meyering]

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.