I'm not against this change in principle, but I wanted to point out that your second and third bullets are criticisms of our current release process, not of the release uri.

FWIW, it's actually defined here in the old site's repo, via a redirect in the new site. Personally, I'd prefer to just get rid of the redirect and make updating the tag on the new site a part of the release manager's document.

This was broken since the time grpc.io website was updated. We have been updating the document every release as it is part of the release process now and it not a big overhead to do that. See config.toml in grpc/grpc.io. It shows:
[params]
grpc_release_tag = "v1.25.0"
grpc_release_tag_no_v = "1.25.0"
grpc_java_release_tag = "v1.26.0"

I am not totally convinced that this needs to go. I think this is a nice way to point to the latest stable release instead of asking users to replace RELEASE_TAG_HERE in various instructions. Beginners like to just cut and paste.

This should fix the redirect and break the dependency on the old site.

@gnossen thanks for the fix.

@srini100 I understand that the idea is to make the commands copy-and-pastable, which is useful, but I think that the argument that the resulting command is not very readable (as a beginner, I can imagine being confused about what the subcommand $(curl -L ...) does).

Btw, on windows, the readability issue is much more apparent - the original command powershell git clone --recursive -b ((New-Object System.Net.WebClient).DownloadString(\"https://grpc.io/release\").Trim()) https://github.com/grpc/grpc is a real mess and completely hides the purpose of the command (which is to do a git clone; imagine trying to decode that as someone who is not super familiar with git, because they are used to a different version control).

Besides that, I'd understand if we used this "get the latest version" trick in one or two places in the repo (the actual getting started docs), but seeing it copy pasted in many different places that have a different (e.g. loadbalancing tutorial) focus seems off.

Btw, for the tutorials on grpc.io page, things work better because the page renders the right version number automatically - that a much better approach and it doesn't impose intellectual burden on the user.

@jtattermusch An alternate approach would be to start updating a mutable release tag on Github with each release. Then we could advertise git clone -b release https://github.com/grpc/grpc

@jtattermusch An alternate approach would be to start updating a mutable release tag on Github with each release. Then we could advertise git clone -b release https://github.com/grpc/grpc

I am not a fan of that either. None of the open source projects I know of does this.
This is definitely a question of taste, but I'm more in favor of a solution that requires no extra maintenance steps and is conceptually simple and completely transparent to the users, even though it might cost users one extra (trivial) manual step.
Another is argument is that anyone who's serious about using gRPC in a real project likely won't mind looking up what's the latest release version. Staying aware of the release notes and regularly checking if one should/shouldn't upgrade to the next release is something I'd recommend anyway. So I see pointing people to https://github.com/grpc/grpc/releases as something rather positive.

@srini100 grpc.io will stay the same in the sense that I will replace occurrences of the curlable link with a token that will be rendered directly into the page.
See PR grpc/grpc.io#79 that does exactly that.