+<p>
+ Go 1.21 adds improved support for backwards compatibility and forwards compatibility
+ in the Go toolchain.
+</p>
+
+<p><!-- https://go.dev/issue/56986 -->
+ To improve backwards compatibility, Go 1.21 formalizes
+ Go's use of the GODEBUG environment variable to control
+ the default behavior for changes that are non-breaking according to the
+ <a href="/doc/go1compat">compatibility policy</a>
+ but nonetheless may cause existing programs to break.
+ (For example, programs that depend on buggy behavior may break
+ when a bug is fixed, but bug fixes are not considered breaking changes.)
+ When Go must make this kind of behavior change,
+ it now chooses between the old and new behavior based on the
+ <code>go</code> line in the workspace's <code>go.work</code> file
+ or else the main module's <code>go.mod</code> file.
+ Upgrading to a new Go toolchain but leaving the <code>go</code> line
+ set to its original (older) Go version preserves the behavior of the older
+ toolchain.
+ With this compatibility support, the latest Go toolchain should always
+ be the best, most secure, implementation of an older version of Go.
+ See “<a href="/doc/godebug">Go, Backwards Compatibility, and GODEBUG</a>” for details.
+</p>
+
+<p><!-- https://go.dev/issue/57001 -->
+ To improve forwards compatibility, Go 1.21 now reads the <code>go</code> line
+ in a <code>go.work</code> or <code>go.mod</code> file as a strict
+ minimum requirement: <code>go</code> <code>1.21.0</code> means
+ that the workspace or module cannot be used with Go 1.20 or with Go 1.21rc1.
+ This allows projects that depend on fixes made in later versions of Go
+ to ensure that they are not used with earlier versions.
+ It also gives better error reporting for projects that make use of new Go features:
+ when the problem is that a newer Go version is needed,
+ that problem is reported clearly, instead of attempting to build the code
+ and instead printing errors about unresolved imports or syntax errors.
+</p>