Time scale for major versions

[est31]

Seeing #1584 considering a Rust 2.0 release less than one year ¹ after 1.0 was released I am wondering, what time scale is projected for major, feature breaking, versions of Rust. 1584 says itself that it should take a "long time" until a major release that removes macro_rules, but I wonder how long a "long time" is.

I personally really like the quality of C/C++ that you can write a program, and three years later it still compiles and works. Yes, it means the language contains lots of legacy luggage, but I can live with that.

So knowing which time scale the rust language pursues for their major releases would I guess be very helpful for people coming from more stable languages like C or C++.

The other thing I am wondering about is how much breakage a major version should contain. If there really must be a major version every 1-3 years, should one major version be enough to rework a big chunk of the language, like the macro system.

Note that I don't oppose the general idea of having a new macro system, in fact I do think that the macro system could use some improvement.

¹: "less than one year" applies to the act of considering the 2.0 release, not of the planned date of the 2.0 release

[BurntSushi]

I don't see #1584 considering a Rust 2.0 release anywhere.

I'm not aware of any specific plans for a Rust 2.0 at this time.

[est31]

@BurntSushi see the last paragraph:

What to do with `macro_rules`? We will need to maintain it at least until `macro!`
is stable. Hopefully, we can then deprecate it (some time will be required to
migrate users to the new system). Eventually, I hope we can remove `macro_rules!`.
That will take a long time, and would require a 2.0 version of Rust to strictly
adhere to our stability guarantees.

[BurntSushi]

@est31 Right, folks speculate, it happens. I saw comments about 2.0 before 1.0 was released. Doesn't really mean much with respect to the time table as far as I know. (And, to be clear, I don't think there even is a time table. The focus is on the train, I think. :-))

[dashed]

Isn't rust's versioning following semver? http://semver.org

[arielb1]

The macro system was a known issue when we released 1.0.

[golddranks]

Concerning the @est31's worry that your programs won't compile three years later.

Note that if – if – the 2.0 release deprecates just library and syntactic stuff, it wouldn't be too crazy to support building 1.0 crates and 2.0 crates, and linking them together – as a compiled language this might be easier to do than with Python (hard to support two semantics in one interpreter), which is still struggling with the adoption of Python 3.0. This, along with some kind of rustfix (maybe even as a service that sends pull requests!) tool plus crater, would allow smoother transition to 2.0. Then, when the amount of 1.0 crates in use are sufficiently low, 3.0 could drop the support for linking 1.0 crates.

[alilleybrinker]

One thing that's important to understand is that Rust and C++ follow very different versioning models. The C++ standard is updated all at once on a roughly three year cycle (this started with C++11). In between this, compilers work on implementing currently standardized features, as well as implementing custom features, and implementing proposals under the experimental namespace as a way to test out ideas as they go through the standardization process. C++ the language has no notion of "major" vs. "minor" changes, although the compilers do, and each compiler defines its own versioning scheme.

In Rust, the language and compiler are designed in lock-step, and while there exists some literature (in the RFCs) about what is part of "standard Rust" and not an imprlentation detail, much of Rust is de-facto defined by what's implemented in Rustc, as well as the views and writings of the Rust team.

As far as 2.0 is concerned, it would only make sense to go to 2.0 if there were major backwards incompatible changes deemed necessary for the language to grow. While we have had some backwards incompatible changes in 1.0, they've all met the standard of the predefined exceptions Rust allows to SemVer.

Basically, we don't have a reason to hit 2.0 right now, and won't do so just for marketing. And comparing Rust versioning with C++ versioning is a real apples to oranges comparison.

[nrc]

re #1584, just to clarify, there are no plans at all for a 2.0 at this stage, just speculation on the kind of thing that might require a 2.0 at some point. There might be things that force our hand sooner, but as far as macros are concerned, we are looking at several years until we get to the point where we can remove macro_rules and that may or may not cause a 2.0.

[glaebhoerl]

I do think it would be a good idea to start tracking "backwards-incompatible things we would like to change the next time we release a major version" all in one place somewhere. Qt does this, for example.

[BurntSushi]

There is a label (rust-2-breakage-wishlist), but only has 4 (closed) issues.

[nrc]

Closing this issue since there is not much discussion happening nor left to have and there is no artefact that would satisfy it.

There are currently no plans for a 2.0, and when it becomes a possibility it will be discussed thoroughly in a public forum.