Because they haven't actually broken backwards compatibility, but rather allowed people to opt-in to incompatible changes by setting a flag.
My understanding from reading the article is that they have broken backwards compatibility; things using the new keywords that were introduced (e.g., "await") will no longer compile.
I think part of the confusion here is that there are essentially two things: there's the compiler, and there is the language itself. It appears (from the article) the compiler can presently support compiling either "edition 2015" or "edition 2018" of the language. (So, it's not the compiler's major we're bumping, rather, it's the language's.)
That flag which says which "edition" to use could just as easily specify which SemVer major version to use. So, instead of saying "use Rust edition 2015" or "edition 2018" it would just be "Rust (the language) v1" or "Rust (the language) v2". There's no difference aside from the naming.
The year doesn't particularly add anything, and obscures if we're jumping over multiple "barriers" of breaking changes or not. I'm not actually sure that that really matters.
My only thought is that having completely different looking things might be better in that it just visually distinguishes the two better. I've repeatedly seen devs muddle the difference between the language, and a implementation of the language, and what the language guarantees and what the implementation happens to do.
> All existing code compiles and will continue to compile with no changes into the future.
My point, again, is that it won't compile without changes in the new edition. "Edition" is the word that was chosen (and it's not necessarily a bad word), but what it is is a version for the language. Whenever a backwards incompatible change (or set of changes) is going to be made to the language, that's a new "edition", but you could just say "version" and it would be as accurate.
Again, consider the language and compiler as separate entities, each with their own API, and I think it becomes clearer. Changes have been made to the language (e.g., the addition of new keywords) that render strings previously valid in the language now invalid, or valid with a changed meaning. In any system, this is a breaking change. This change could, were SemVer used, be identified with a major version bump.¹
That the compiler (which itself has a version number, separate from the language now) is capable of recognizing a flag and switching internally which version of the grammar it uses is great, but again, proof that there exists a version of the grammar (called "edition").
¹But honestly, that ship has sailed for Rust. And that's fine, and I think it's just a different term, and that it has a good chance of helping better convey the meaning by simply being different. But the argument that, under that, it's essentially SemVer, is nonetheless true.
(That at present the compiler and the language are very much intermixed makes this much more muddled. Were the language's definition more formal, I think this would all get much clearer, as we could ignore rustc, and talk about the language.)
That's not backwards compatibility, it's forwards compatibility. Whenever any language adds a new feature, using that feature breaks the build on old compilers. Setting `edition=2018` is no different. But the important thing is that old code continues to build unmodified on new compilers. That's what the edition system is preserving.
This is not the case.
That the compiler has the user opt-in to the never version by setting a flag is irrelevant, for the discussion of versioning. (Now, for an end-user, I think it's great: you do not want to automatically break working code. I'm not saying the flag shouldn't exist, I'm saying the flag exists because the change is breaking.)
Would anyone like to share other examples of this sort of thing (such as in other compilers or tools)?