As a curiosity, is there a link that I can read more to understand the reason behind this condition in the release policy? The only other issue I could find was #36717. So maybe I am not looking in the right place

@elfgoh There’s some additional motivation described on the Go Release Cycle page:

One of the criteria for issuing a release candidate is that Google be using that version of the code for new production builds by default: if we at Google are not willing to run it for production use, we shouldn't be asking others to.

I recommend reading that entire page as it provides context for each milestone and the process leading up to the final release.

if we at Google are not willing to run it for production use, we shouldn't be asking others to.

Thanks @dmitshur . I was guessing the above, but wanted to be sure 🙇

I understand that there can't be a release candidate until release-blocker issues like this one are closed, and we seem to be three weeks behind schedule, so I'm wondering if anyone at Google could give some insight into what blockers are being encountered.

I completely understand that the pandemic is affecting everything, and that releases are often difficult, but at the same time it almost seems like nothing is happening from the outside :)

Hi @mvdan! I had intended to write an update at the end of last night, but was sidetracked. We're very close to switching to the default internally, which we use as a blocker for external use. As you know, we want the Go community to be confident that we're comfortable running it ourselves before we ask you to.

As of this week, in our testing we've uncovered one new potential issue internally that we will be filing a GitHub issue for if it's not specific to Google. We are otherwise ready to use Go 1.15 internally, so hopefully this can be resolved quickly. I'll try to see if we can file an issue for that today to help stick to our ideals of transparency.

It's worth also mentioning that a couple brittle tests were found this week that ran into issues with #36654. Typically, we don't file GitHub issues for some internal testing mistakes, but I'll see what we can do for the remaining issue once we know a little more about it.

Default has been switched.

For the amusement of the curious, the last blocking issue turned out to be caused by a test relying on the formatting of a date in the PDT timezone in the year 49,886,460.

(For the record, date formatting in the year 49.886,460 was changed by the fix for #36654.)