Automatically pushing the new version tag in release process

[Reuben Thomas]

Currently, HACKING contains:

* Push the NEWS-updating changes and the new tag:

v=$(cat .prev-version)
git push origin master tag v$v

Is there some reason this can't or shouldn't be done at one of the release
stages? Either in the release or the release-commit target?

(I noticed that this step had escaped from my more streamlined GNU Zile
release procedure, but I couldn't think of a reason to make it an extra
manual step.)

[Jim Meyering]

Post by Reuben Thomas
v=$(cat .prev-version)
git push origin master tag v$v
Is there some reason this can't or shouldn't be done at one of the release
stages? Either in the release or the release-commit target?
(I noticed that this step had escaped from my more streamlined GNU Zile
release procedure, but I couldn't think of a reason to make it an extra
manual step.)

Hi Reuben,
I prefer to keep it separate.

The preceding step, "make upload RELEASE='X.Y TYPE'" may actually take
days, if it's one's first time and one has not yet made sure the FSF
admins have added the right GPG key to the set from which uploads of
the package in question are allowed. Technically, I suppose one could
poll the server, and automatically push once the asynchronous uploads
are confirmed to have succeeded.

I prefer not to push it right after creating the commit and tag for
the above reason, and also because I usually do some last-minute
testing of the release tarball before uploading it (as suggested in
README-release), and numerous times have had to un-tag, and delete the
local-only release commit so that I could make an additional fix
before resuming the release process.