If this is so, how are they maintaining edition compatibility? It seems like you could write code for the 2015 edition that would build with the new compiler, but not an older (2015 edition compliant) compiler.
The edition compatibility story here is interesting. When the 2018 edition came out, the new borrow checker was only turned on for code on the 2018 edition. Meanwhile, in the 2015 edition, it would run both borrow checkers and yield a warning if your code passed the old borrow checker but not the new one. After a migration period, the new borrow checker was eventually made the default on the 2015 edition as well. Because of the aforementioned soundness bugs fixed by the new borrow checker, this was seen as acceptable (soundness fixes are explicitly allowed by the stability policy, although the Rust developers still try to provide migration periods to make them less painful).
I like that previous editions get new features when possible, unlike say C++, but I wish they'd gone with semantic versioning for the language version, like python did when both 2 and 3 were active. Oh well, I just need to remember that the edition is like the major version, and compiler version is sort of like minor version, and both are needed to specify forwards compatibility.
2.17
1.17
The issue is that semantic versions are a hierarchy, whereas Rust edition x compiler version are a matrix
They do not promise new code works with old compilers