60 ms·

Well, that's my point! You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. I might be mistaken but my fe

Well, that's my point! You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. I might be mistaken but my feeling is that most of the rust devs are using the nightly version thus the reason of a tool to debug/test different versions.

pcwalton 10y ago
> You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. Can you specify, in particular, what you think Rust is not doing that it should be doing?
- themihai 10y ago
  I would like the code developed now to work with all subsequent rust releases until 2.0 so that I can take advantage of improvements to the compiler and std libraries without any additional effort. A small effort may effort may be required if there were security/critical bugs.
  - pcwalton 10y ago
    > I would like the code developed now to work with all subsequent rust releases until 2.0 so that I can take advantage of improvements to the compiler and std libraries without any additional effort. Rust is doing exactly that.
  - moosingin3space 10y ago
    The Rust compiler is run against all the open-source crates published on crates.io to measure the impact of changes prior to release.
  - dikaiosune 10y ago
    Don't use nightly, and your wish is granted!
steveklabnik 10y ago
What if I would like to guarantee this property for my own code? As well as testing each nightly as they come out, in case something accidentally breaks, so it can be fixed before a release? This tooling assists greatly with that. (And dbaupp is correct that it's not always about testing; not all of the OS dev features are in stable yet, so nightly is the only option for that kind of project.)
- themihai 10y ago
  Testing nightly makes sense. >>What if I would like to guarantee this property for my own code? I think that should be an exception if the backward compatibility is to be trusted.
  - steveklabnik 10y ago
    Right, but humans are fallible. Bugs happen. It's a good idea to test early and often, just to make sure: Travis runs are extremely cheap. Better to catch accidents before they make it into an actual release. More testing doesn't hurt anyone.
dbaupp 10y ago
He didn't say he was "testing" with nightly: some experimental features only work on nightly (which, being experimental, the features may change in breaking ways, but that's why people have to opt-in to using a nightly) and so if one of your project needs one of these features, you can use rustup to get nightly for just that project and the stable releases for the rest of your work. A staged release cadence with different levels of surety gives people the ability to play with features as they're developed to make sure those features solve the problems they're trying to solve (in the best way) by giving time for real-world experimentation and feedback. A feature can graduate from nightly-only to stable, and it then has a strong backwards compatibility requirement. The nightly experimentation period is valuable to get those features perfected before people can start relying on them more broadly.

pcwalton 10y ago

> You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. Can you specify, in particular, what you think Rust is not doing that it should be doing?

themihai 10y ago
I would like the code developed now to work with all subsequent rust releases until 2.0 so that I can take advantage of improvements to the compiler and std libraries without any additional effort. A small effort may effort may be required if there were security/critical bugs.
- pcwalton 10y ago
  > I would like the code developed now to work with all subsequent rust releases until 2.0 so that I can take advantage of improvements to the compiler and std libraries without any additional effort. Rust is doing exactly that.
- moosingin3space 10y ago
  The Rust compiler is run against all the open-source crates published on crates.io to measure the impact of changes prior to release.
- dikaiosune 10y ago
  Don't use nightly, and your wish is granted!

steveklabnik 10y ago

What if I would like to guarantee this property for my own code? As well as testing each nightly as they come out, in case something accidentally breaks, so it can be fixed before a release? This tooling assists greatly with that. (And dbaupp is correct that it's not always about testing; not all of the OS dev features are in stable yet, so nightly is the only option for that kind of project.)

themihai 10y ago
Testing nightly makes sense. >>What if I would like to guarantee this property for my own code? I think that should be an exception if the backward compatibility is to be trusted.
- steveklabnik 10y ago
  Right, but humans are fallible. Bugs happen. It's a good idea to test early and often, just to make sure: Travis runs are extremely cheap. Better to catch accidents before they make it into an actual release. More testing doesn't hurt anyone.

dbaupp 10y ago

He didn't say he was "testing" with nightly: some experimental features only work on nightly (which, being experimental, the features may change in breaking ways, but that's why people have to opt-in to using a nightly) and so if one of your project needs one of these features, you can use rustup to get nightly for just that project and the stable releases for the rest of your work. A staged release cadence with different levels of surety gives people the ability to play with features as they're developed to make sure those features solve the problems they're trying to solve (in the best way) by giving time for real-world experimentation and feedback. A feature can graduate from nightly-only to stable, and it then has a strong backwards compatibility requirement. The nightly experimentation period is valuable to get those features perfected before people can start relying on them more broadly.