-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tools and beta channel #38
Comments
As a potential proposal for this, we could change how we version Rust standard tools, so instead of having Rust 1.26 contain RLS x and rustfmt y, we instead ship RLS and rustfmt on their own schedules (perhaps faster than all of Rust). Essentially, we would gain the ability to promote any given nightly RLS to beta/stable Rust when desired, without shipping a new version of Rust. This is a fairly major change to rustup, and the related infrastructure, but does seem at least plausibly reasonable: RLS, at least, is in theory not coupled to a particular version of Rust, so to speak. I don't feel great about this proposal though. Either way, I think increased QA on beta would be excellent, though I'm not entirely certain what that would look like. I do think this is a wider problem to attempt to solve -- maybe we can sell developers on using beta-channel Rust instead of stable-channel locally, since in theory it has most of the same stability guarantees while greatly enhancing our ability to QA stable releases... |
There might be breaking changes to the driver API or save-analysis version that would prevent this working, but those are rare. |
One question that might help this conversation is: who do we expect to use the beta channel currently? I have yet to find any project that uses the beta channel (beyond listing it in Travis). I suspect few developers (without considering tools) are actively using beta at all. |
This is the primary use case for the beta channel - we recommend projects use it in their CI so they know 6 weeks in advance if stable is going to break their project (and can file an issue if appropriate). |
I can totally see having a clippy build in travis (though that'd be currently breaky-happy), but how would one test RLS via CI? |
Perhaps it's useful to enumerate the tools that aren't being sufficiently tested? For instance I was wondering (because I lack the knowledge): does the use of the beta channel in Travis CI test beta cargo? The most I know is rust-lang/rust depends on cargo as a submodule in https://github.com/rust-lang/rust/tree/master/src/tools. |
They are tested, the problem is there are always some things that are problems, but not caught by tests. |
Essentially nobody is using tools on the beta channel. The effect of this is that tools are hitting the stable channel with fairly serious bugs (e.g., rust-lang/rust#50646, rust-lang/rustfmt#2695).
We need to do something to address this, either:
The text was updated successfully, but these errors were encountered: