Use gRPC tags rather than branches in docs

[carl-mastrangelo]

Tags are more stable than branches, and don't change with time. Prefer using them for the "release".

Generated with:

• find . -print0 | xargs -0 -n 1 sed -i s/grpc_release_branch/grpc_release_tag/g
• Updating _data/config.yml to point to v1.14.0
• Updating faq/index.html to use the word "tag" rather than "branch".

Over all, the word "branch" very rarely appears in this repo.

[hsaliak]

Branches point to the latest stable point of a branch and include any patch release work. Tags, especially .0 do not.

By using tags, are we not potentially pointing to 'less stable' points in a release branch, than directly pointing to branches? Or do we now need to update this for patch releases as well?

[srini100]

Branches do not necessarily point to stable commits at all times but release tags do. We will have to update this for patch releases as well.

[hsaliak]

I thought every commit to a stable branch is usually a patch fix, and has to pass a full suite of tests. Ie: we are stable at all times.

[srini100]

Sometimes we wait for multiple commits in the branch before doing a patch. Patch may go through RC process and deemed to be more stable than individual commits. It's an extra burden to update the yml file. Java has been doing this for some time.

[hsaliak]

Approved -- should we update the release guide to state that patch versions require a version bump on the website?

[carl-mastrangelo]

@hsaliak yes, I updated it.