Wait, I don't understand these version numbers. Wasn't the previous release 0.9? I was expecting the new release to be 1.0, or 0.91, or something like that. Maybe this is standard practice for all I know.
A 1.0 release of Rust is targeted for later this year. There will be at least one more minor version (0.11), and possibly more, before that point.
If so, that virtually guarantees some regret after it becomes stable and new users flood in with new use cases that need breaking changes to address in an optimal manner.
Edit: Perhaps I was too subtle. If you think rust is something that may meet your needs in the future, you should do future-you a favor and start using it now when there is still time to remove warts in a backwards incompatible way.
I can understand the desire for stability before wrapping your head around a new language (typestate..), but if you're interested in Rust then you either patiently watch from afar, or at some point you just jump in and live with the breaking changes.
Semver seems like a straightjacket at the discontinuity of 0.x->1.0 if you don't want to commit to significant velocity of major versions. Perhaps the thing to do is define a second pre-1.0 series at 0.99.x, where breaking changes are made deliberately and include a source rewriting tool where possible?
That's the kind of vague goal that people will keep using as an excuse for not focusing on stability, and providing a product that's actually usable.
When it comes to programming languages, it's dangerous for their implementors to not produce something that's seriously usable as soon as possible, even if it means accepting some imperfections in the early stable versions.
With each passing day, Rust becomes closer to being something like Perl 6: anticipated, probably useful, but never actually "ready" enough to be usable. While I'm more optimistic about Rust potentially having a far brighter future than Perl 6, the lack of stability does cause unease.
https://github.com/mozilla/rust/issues?direction=asc&labels=...
If anything, that's yet another way to justify not getting a stable release out there. It's the old "We can't release yet, still have bugs to fix!" trap that catches many software development teams.
There will always be some issues, so insisting on a vague notion of "perfection" becomes far more harmful than just getting at least something out there than users can actually use.
Yes, sometimes the language/lib changes and you have to go through and edit all of your existing code. You can stick with point releases to minimize this, but most likely you won't want to, because these breaking changes fix problems and annoyances!
If you take a look at these changes for 0.10, they make progress on the language itself, and leaving these things as-is to stabilize the language would have been a terrible mistake. There are more of these in the line (DST..), as there should be. IMHO, Rust will be "ready" when such changes stop creating real progress.
Having watched Rust for several years now, it has always been apparent that it isn't an overnight language. Despite the goal of being based on only existing research, getting new implementations of ideas right takes careful deliberation. A large part of language design is getting the core features to play well with one another in ways that make sense, and creating well-thought-out core libraries that properly implement standard abstractions. Every inconsistency and incompleteness at this stage will lead to constant (poor) reinvention of these concepts to achieve the missing capabilities, and a subsequent proliferation of ecosystem glue code to make the different implementations communicate. A large part of why dynamic languages can be so expressive is that their core abstractions contain enough indirection to add missing functionality in a backwards-compatible manner, but a close-to-the-metal language simply does not have that luxury.
The point of semver is to stick to a standard, instead of every project deviating from common practice in subtly incompatible ways.
Actually, since they are doing backwards incompatible changes in every release, this version would be more like 10.0.0.
They are deviating from semver for now, I hope they get on it properly for 1.0.0 and beyond.
Here's the issue for getting us to adhere to semver proper: https://github.com/mozilla/rust/issues/11396
It's just two numbers separated by a dot (major version number DOT minor version number).
Perhaps if we switched to using something like 0-10 or 0:10, people wouldn't expect any reference to . to mean a decimal number.