publish_release: git tagging procedure

[sdarwin]

Includes the 'git tag' commands in publish_release.py.

This is a step closer to having publish_release.py take care of everything in the release.

It's opt-in with the --git-tag flag. Otherwise nothing changes, and tagging can be done manually as before.

[sdarwin]

@mclow what steps do you follow with rc release candidate git tags? Do you skip that completely? Or tag and then delete later?

[sdarwin]

@mclow please review when you have a chance. I tested these changes and it seems fine. Before the "git push" step, the script pauses and allows you to check git tags locally and decide if they should be pushed to github.

[mclow]

A quick question here - are you tagging the HEAD of each of the modules, or the commit that is referenced in the super-project?

They ought to be the same - but sometimes someone commits something to 'master' even though we tell them not to - and turn off automatic merging to the super project?

[sdarwin]

are you tagging

Consider the steps on https://github.com/boostorg/wiki/wiki/Releases%3A-Preparing

git submodule update --init --recursive --checkout
git tag boost-1.78.0
git submodule foreach 'git tag boost-1.78.0'
git push origin boost-1.78.0
git submodule foreach 'git push origin boost-1.78.0'

Is the wiki correct?
Those are the steps the script is following, so it should be the same.

Since "git submodule update" will retrieve the commit referenced by the superproject, that will be the tagged commit.

Also, immediately before "git push", the script pauses, and you can check the state of the tags.