> The compiler will always support old code written against older editions, but the language can still introduce breaking changes in newer editions. Developers can either opt in to new editions and migrate their code, or do nothing, and things continue to work fine. There is seamless/transparent interoperability.
This is exactly what the GODEBUG scheme described in the article is intended to allow.
The Go approach does indeed seem to enable similar functionality. Although I'm not quite sure I understand how the individual settings and the module level version declarations compose, and how much complexity that introduces.
With both module-level versions and GODEBUG, the whole thing does seem quite a bit more complicated than editions.
No. If a module's go.mod files declares go1.21, the compiler will use go1.21 semantics when building it, even if 1.22 has already been published and the module is being used from a 1.22-enabled program. This is explicitly mentioned in the blog post.
"This crate is edition X, and an edition comes out every 3 years or so" is much easier to deal with.
It reminds me a bit of Haskell language pragrams, which can be toggled per source file (module), and which are a huge mess.