4 ms·
I think it's worth noting that 1.0 is a stable release, meaning that any 1.x future release will not introduce breaking changes. But that does not preclude them
by scott_s 12y ago
I think it's worth noting that 1.0 is a stable release, meaning that any 1.x future release will not introduce breaking changes. But that does not preclude them from eventually releasing a 2.0 which does break compatibility with 1.0.
That allows them to tell people that, yes, they can depend on the fact that the language and API will not change from, say, 1.2 to 1.3. And that they will continue to support it for the foreseeable future. But I imagine that eventually they will want to make breaking changes, as they certainly won't get everything completely right with 1.0. But that will be clearly marked as an entirely new version.
- MichaelGG 12y agoExcept the std lib isn't going stable for 1.0. They have a system that marks which APIs are stable, but a lot of stuff is still unstable/experimental. So it's very possible to write a Rust 1.0 program that won't work on 1.x, if you used those parts if the stdlib. Fortunately, the compiler can warn you of this so you know what you're getting into.
- dbaupp 12y agoThe plan is to have those unstable parts disabled in the stable compiler, so that any program that works with rustc 1.0 will work with rustc 1.x etc. One can use those parts via the nightly branch. The plan is also to try to have much of the most useful parts of the stdlib stable (at least the core functionality). More info: - https://github.com/rust-lang/rfcs/pull/507 https://github.com/rust-lang/rfcs/pull/507 - http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html
- zokier 12y ago> But that does not preclude them from eventually releasing a 2.0 which does break compatibility with 1.0. Which lets us relive the fun times of eg. Dlang 2.0 release or Py3k
- scott_s 12y agoI can't think of a popular language which has not had breaking releases. C, C++ and Java all have.