This issue concerns the rollout of #40276, which is a welcome feature. However, the go get some-main-pkg warning in 1.16 is a bit too scary:

$ GO111MODULE=on go get mvdan.cc/gofumpt
go: downloading mvdan.cc/gofumpt v0.0.0-20201123090407-3077abae40c0
go get: installing executables with 'go get' in module mode is deprecated.
	To adjust dependencies of the current module, use 'go get -d'.
	To install using requirements of the current module, use 'go install'.
	To install ignoring the current module, use 'go install' with a version,
	like 'go install example.com/cmd@latest'.
	See 'go help get' and 'go help install' for more information.
go get: added mvdan.cc/gofumpt v0.0.0-20201123090407-3077abae40c0

This already results in end users filing bugs on projects using go get in their READMEs. For example, see mvdan/gofumpt#94. This will only get worse as end users install 1.16 betas and RCs, and of course the final release.

As the author, I need to be careful with fully switching to go install some-main-pkg@latest, given that a significant portion of users will be using Go 1.15.x even weeks after 1.16 has released. Moreover, my project supports two major Go versions at once, so I can't drop support for 1.15.x until 1.17.x is released.

So, right now, I have three options:

1. Keep the current go get line, meaning people on 1.16.x get the scary warning, and likely send bug reports my way. Not good for anyone.

2. Use the new versioned go install once 1.16 is out, which will break and confuse users on Go 1.15.x for at least months to come. Probably worse than option 1, as option 1 at least worked for all users.

3. Give up and do a "run go install if you're on 1.16, run go get if you're on 1.15", which honestly will probably be the most confusing version to the reader. The README install line needs to be dead simple.

Personally, I think our best course of action is to not formally deprecate go get with binaries in 1.16, giving an extra six months of a transition period without scary warnings for end users. This is important because, as explained above, projects supporting at least two Go versions can't fix this problem - and I think those are a majority.

With the proposed change, I could keep go get in the README until 1.17 is out, then swap it for a versioned go install once 1.17 is out. The pain would be significantly reduced. We do add six months to the wait until we can properly remove the ability for go get to build/install programs, but I think that's the only proper way to have a painless transition.

We could still print a single-line "this go get behavior will be deprecated in 1.17" information message - then 1.17 can formally deprecate, and show a warning telling the user what command they should use instead.

cc @jayconrod @bcmills @matloob @ianthehat @myitcv