6 ms·

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. May

by Dewie 13y ago

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.

aphistic 13y ago
10 comes after 9. The previous release was 0.9, not 0.90.
kibwen 13y ago
Rust uses semantic versioning (http://semver.org/ http://semver.org/). The number after the dot is simply a minor version revision, and can increment without bound. 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.
- yepguy 13y ago
  Unfortunately Rust is not actually using semver, which I always found confusing because they seem to be in support of it, and they even include a semver library in the core distribution. If they were following semver, this release would be version 0.10.0 (notice the patch version). The point of semver is to stick to a standard, instead of every project deviating from common practice in subtly incompatible ways.
  - Tuna-Fish 13y ago
    > If they were following semver, this release would be version 0.10.0 (notice the patch version). 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.
    - yepguy 13y ago
      You are allowed to make breaking changes at any time if your major version is zero.
      - mcguire 13y ago
        Right, because the semver "standard" is inconsistent in that particular way.
        psquid 13y ago
        Yes, but intentionally so - 0.y.z versions are meant to allow you to more-or-less try stuff out without inflating version numbers, with the 0. reminding users that they shouldn't consider it ready yet if they need API/feature stability.
  - kibwen 13y ago
    Right, we didn't really "adopt" semantic versioning until sometime after 0.1, and so we've never really gotten into the habit of including the patch revision (and with one exception, we've never issued a patch for any of our unstable releases anyway). Here's the issue for getting us to adhere to semver proper: https://github.com/mozilla/rust/issues/11396 https://github.com/mozilla/rust/issues/11396
  - brson 13y ago
    There's an open issue for this: https://github.com/mozilla/rust/issues/13289 https://github.com/mozilla/rust/issues/13289
- mindslight 13y ago
  I, for one, hope there are many more minor releases before any 1.0 - as many as it takes, and then some. Given the rate of breaking changes and how awesome they turn out to be, I would really hate to see this extremely promising language get stuck with warts for the sake of expedience. By the time 2.0 is on the horizon, everyone will have gotten used to and even depend on them.
  - nullc 13y ago
    Unfortunately there /seem/ to be a lot of people holding back from using it until the language is stable. 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.
    - mindslight 13y ago
      That theme is exactly what makes me worry that the team will give in to pressure to make a 1.0 before it's really ready. 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?
      - pcwalton 13y ago
        We are going to commit to backwards compatibility at 1.0, but many (not all) libraries will be unstable, and we can always add stuff to the language as long as it doesn't compromise backwards compatibility for existing code. All 1.0 means is "we're going to stop breaking your code, and we have a reasonable, stable platform on which a lot of useful software can be written".
dorolow 13y ago
This is standard practice. The decimal points are generally dividers between major, minor, and patch numbers. Hence why it is not uncommon to see something with a version number like 2.1.4 or similar.
eterm 13y ago
If you pronounce it "Naught point Ten" you should understand how it comes after "Naught point Nine".
andrewaylett 13y ago
It's not a decimal number, it's two numbers separated by a period. So just as '10' follows '9', '1.10' follows '1.9'.
coldtea 13y ago
It's not a decimal number. 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.

by Dewie 13y ago

aphistic 13y ago

10 comes after 9. The previous release was 0.9, not 0.90.

kibwen 13y ago

Rust uses semantic versioning (http://semver.org/ http://semver.org/). The number after the dot is simply a minor version revision, and can increment without bound. 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.

yepguy 13y ago
Unfortunately Rust is not actually using semver, which I always found confusing because they seem to be in support of it, and they even include a semver library in the core distribution. If they were following semver, this release would be version 0.10.0 (notice the patch version). The point of semver is to stick to a standard, instead of every project deviating from common practice in subtly incompatible ways.
- Tuna-Fish 13y ago
  > If they were following semver, this release would be version 0.10.0 (notice the patch version). 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.
  - yepguy 13y ago
    You are allowed to make breaking changes at any time if your major version is zero.
    - mcguire 13y ago
      Right, because the semver "standard" is inconsistent in that particular way.
      - psquid 13y ago
        Yes, but intentionally so - 0.y.z versions are meant to allow you to more-or-less try stuff out without inflating version numbers, with the 0. reminding users that they shouldn't consider it ready yet if they need API/feature stability.
- kibwen 13y ago
  Right, we didn't really "adopt" semantic versioning until sometime after 0.1, and so we've never really gotten into the habit of including the patch revision (and with one exception, we've never issued a patch for any of our unstable releases anyway). Here's the issue for getting us to adhere to semver proper: https://github.com/mozilla/rust/issues/11396 https://github.com/mozilla/rust/issues/11396
- brson 13y ago
  There's an open issue for this: https://github.com/mozilla/rust/issues/13289 https://github.com/mozilla/rust/issues/13289
mindslight 13y ago
I, for one, hope there are many more minor releases before any 1.0 - as many as it takes, and then some. Given the rate of breaking changes and how awesome they turn out to be, I would really hate to see this extremely promising language get stuck with warts for the sake of expedience. By the time 2.0 is on the horizon, everyone will have gotten used to and even depend on them.
- nullc 13y ago
  Unfortunately there /seem/ to be a lot of people holding back from using it until the language is stable. 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.
  - mindslight 13y ago
    That theme is exactly what makes me worry that the team will give in to pressure to make a 1.0 before it's really ready. 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?
    - pcwalton 13y ago
      We are going to commit to backwards compatibility at 1.0, but many (not all) libraries will be unstable, and we can always add stuff to the language as long as it doesn't compromise backwards compatibility for existing code. All 1.0 means is "we're going to stop breaking your code, and we have a reasonable, stable platform on which a lot of useful software can be written".

dorolow 13y ago

This is standard practice. The decimal points are generally dividers between major, minor, and patch numbers. Hence why it is not uncommon to see something with a version number like 2.1.4 or similar.

eterm 13y ago

If you pronounce it "Naught point Ten" you should understand how it comes after "Naught point Nine".

andrewaylett 13y ago

It's not a decimal number, it's two numbers separated by a period. So just as '10' follows '9', '1.10' follows '1.9'.

coldtea 13y ago

It's not a decimal number. 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.