To know when a new version is released, subscribe to golang-announce. Only important announcements are made, so you don't have to worry about being inundated with email.
The More Nuanced Answer¶
A Go release can update the toolchain (e.g., compiler) and/or the packages in the standard library. New features and fixes are implemented for the next release (1.11). Fixes for critical problems that don't have workarounds applied to the current release (1.10) and released as minor changes (1.10.x). Critical fixes are typically related to stability or security. The previous release (1.9) only receives security updates.
This maintenance policy, defined as part of the Go Release Cycle, results in the following maintenance schedule:
|Releases||Maintenance Starts||End of Critical Updates||End of Security Updates|
|Next||1.11.x||August 2018||February 2019||August 2019|
|Current||1.10.x||2018-02-16||August 2018||February 2019|
To receive security updates, which are important even if your production application is in maintenance mode, the latest release of a maintained version of Go needs to be used (currently 1.10.3 and 1.9.7), or the security updates need to be manually back-ported to whatever version you are using.
If you choose to run the latest current release, you will have access to the latest features, fixes, and performance improvements. If you choose to run the latest previous release, you will need to update Go less frequently.
To figure out the update frequency for each choice, I analyzed the Go release since 1.5. Why start with 1.5? The release cycle was shifted before 1.5 was released to better work around conferences and holidays. This shift resulted in 6 months between the 1.4.2 and 1.5 releases. This longer period conveniently provided some extra time for converting and testing the compiler as it was changed from C to Go.
|Number of Updates||26||11|
|Mean Time Between Updates||5.8 weeks||14.1 weeks|
|Standard Deviation||3.7 weeks||11.6 weeks|
|Next Update||1.11 in August 2018||1.10.5 in mid November 2018|
The updates for the current release do not include minor releases (i.e., security) to the previous release (e.g., 1.7.6), 1.7.2 (which was tagged, but not released), or 1.8.2 (because 1.8.3 was announced to be released the next day).
Figuring out the updates for the previous release was trickier. The difficulty comes in ensuring that release you are using has the latest security fixes. For example, right before 1.6 was released, the latest previous release was 1.4.3. When 1.6 was released, the latest previous release became 1.5.3. However, the list of updates for those tracking the previous release does not include 1.5.3, but skips to 1.5.4 (which was released after 1.6). The reasoning behind this is that all the security fixes that have been applied to 1.5.3 are also present in 1.4.3. Therefore, from a security perspective, these releases are the same, and there is, therefore, no reason to update from 1.4.3 to 1.5.3. The next update, therefore, is 1.5.4, the first release of a previous version after 1.6 was released.
Every update comes with risk. The risk while upgrading to a new minor release (e.g., 1.8.1 to 1.8.3) is low because minor releases only fix critical problems. The risk while upgrading to a new major release (e.g., 1.10.3 to 1.11 is greater, but mitigated by the Go 1 compatibility promise. This means that you can expect that any code that compiles and runs correctly will do so with any 1.x version. If it does not, please file an issue.
I generally recommend using the latest current release. Other than receiving the benefits of the latest version, the more frequent updates will keep whoever is doing the updating familiar with the process, and therefore less likely to make mistakes. Furthermore, most of those updates are minor releases, which are less risky and therefore should be easier to apply.
If you want to know some reasons the latest release is not being used, checkout Ed Muller's State of Go 2016 Survey. You will have to dig through the raw results to find the answers.
The result of this entire thought process is the flowchart at the top of this page. It will be updated soon after every Go release.
What about beta and release candidates?¶
The analysis above does not include the beta and release candidates that are released before the release itself. Go 1.11 betas are expected in June 2018, release candidates in July 2018.
Trying out the betas and release candidates and filing issues with them is a great way to help the Go project.
If you want to try them, make sure and educate yourself about the betas and release candidates. Your decision should also include your testing and deployment capabilities along with your risk capacity and resources for the more frequent updates leading up to the actual release.