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.
