-
Notifications
You must be signed in to change notification settings - Fork 894
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
Support stable-X
as a version descriptor
#2291
Comments
It's an interesting idea, certainly. However it wouldn't fit directly with If you're insistent on doing it via a Travis matrix then it'd have to be |
At that point, we could add support for the requisite channel name shape to |
I guess the Debian equivalent would be old-stable and old-old-stable, if the numeric component causes an issue. |
I think oldstable and oldoldstable are more plausible just because |
Do we know from channel data the stable version? We could do the arithmetic easily enough in rustup to synthesise new pseudo channels, no? |
Such synthesis would change the download-channel-install-channel model which IMO would be moderately awkward; though as I said before yes it'd be possible. However the ideal would be if the pseudochannels were handled on static.rlo, otherwise we have to start faffing with working out which patch level is the newest for a version (e.g. if stable is 1.35.0 and the user wants stable~1 do we install 1.34.0 or the more useful 1.34.2 ?) So many roundtrips would make |
I think a good approach would be to create new manifests for
|
Yeah, I like using |
The good default to me is using latest patch release. As patch releases often Edit: minor -> patch |
I'd call that the patch release, as the |
So I like both @pietroalbini 's idea of |
I'd prefer not to have |
I guess we could have a go. I don't like the double-downloading of manifests but I suppose if the user is opting in then they're prepared to pay the cost. So we define |
Yeah pretty sure we can backfill static.rlo. |
We now have major.minor channel files present on the dist server, so we're a step closer to being able to do this. If someone wanted to have a go at implementing the channel parsing and handling the double-manifest-download then we can see how it works. |
@rbtcollins This seems a bit complex, and I don't have a concrete timeline, but I still want to give this one a try. Could you please mark this issue as claimed? |
Before actually trying to implement this change, I'll try to share my thoughts on this issue below: De-sugaringIt seems that the main use cases for this IIRC, in today's model,
To me, it will be too weird to actually make Does this sound acceptable? (cc @kinnison @joshtriplett) Abandoned alternative plan
Full syntaxThe current syntax for a toolchain spec is: CHANNEL[-YYYY-MM-DD][-TARGET] ... where:
... and I suggest to add a possibility for the 2nd part: an unsigned integer of at most 3 digits, so that it becomes: CHANNEL[-YYYY-MM-DD|-WWW][-TARGET] This would then accept the following (still assuming the current stable is on
Footnotes |
How I would direct rustup/cargo to do a build with the resolved toolchain? Will |
@thejpster It is still a bit too early to talk about this. As I see it, there are two ways of defining the semantics of
I'm still hesitant about this, initially I wanted to go with 1. (as posted above), but after some discussions with other devs it seems to me that 2. is a better option. After all, these two semantics should be equivalent on CIs, but what if someone wants to do this on their own dev machine? But on the other hand, I don't currently know if this virtual channel thing does exist. If it doesn't, I might have to invent the wheel myself :o There are other similar things to decide, for example:
Footnotes
|
I think I agree that (2) would provide a better UX, although it would be more work to implement. (I also agree the |
Thank you! IIRC Debian use oldstable and oldoldstable. |
@thejpster Thanks for the help! This is indeed very clear without using any weird characters! I'll consider using this name or at least some variant of it :) |
I think there will also be use cases for old-old-old-old or even old-old-old-old-old-old-old-old, so I'd probably try to get a number in there rather than relying on repetition like this. |
There are two design points referenced in the recent message.
The proposal linked above is that when rustup encounters a name with a version offset (@kinnison used The question about whether we end up with e.g. a toolchain on disk called What do you think of this possible bit of documentation for the feature.
Reasons why I propose this:
|
I'm still wondering if there will be a 2.0 moment of Rust, and how we might design this feature to be future-proof in that respect.
One downside of this approach, I imagine, would be too many old toolchains on one's disk if they choose to install locally. 1.69, and 1.70 after that... There doesn't seem to be a "garbage collection" mechanism. |
When there is Rust 2.0, I believe rustup is very likely to ship breaking changes along with that. Thus not an issue from my pov. |
I wonder if we can support this without mandating that the stable toolchain is installed? Or do we think that ~everyone has stable installed anyway so there's not much point? |
@djc I think @rbtcollins wants stable to be installed as an anchor point so that we can effectively know what This IMO is also different from my original proposal, in which I wished to resolve Ideally we can do both based on whether |
I realise I didn't cover one of the design constraints. Because rustup proxies are in the critical path for build time, we need a design that doesn't pay (much) overhead, and that works when the internet is down. The (much) overhead - its probably ok to run rustc, or parse the stable manifest or both, when a proxy is invoked with no RUSTUP_TOOLCHAIN set. Once set, it needs to be set to a concrete value that won't trigger resolution again. I'm not sure what I'm proposing is necessarily the best, but it seems ok at current thinking to me.
Using
|
Something I've adopted in my projects and am also starting to use in cargo is to have RenovateBot automatically update my MSRV. e.g. see rust-lang/cargo#12381 Would something like that existing lower the priority of implementing a feature like this directly in rustup? |
An alternative possible design is that rustup should expose |
@djc Yes, that looks interesting, which could even free us from caring about |
The tricky part is how this works in workspaces, which don't natively have a |
Forgive me if I quote myself:
|
@thejpster I'm not sure exactly what you are trying to convey. Is it that you want the +stable-X to be trailing along without you having to update the |
My OP I think dates before rust-version existed so yes, we wanted MSRV to move without changing anything in the repo. |
So how/when are you going to the |
I don't know that anyone has thought about it. I would probably publish without a rust-version and say in the README "If you're more than three versions behind stable, this might not work" |
If the answer is "don't set a rust-version", then this feels too specialized of a feature. The ideal we should be working towards is setting rust-version
|
Then I'm happy to declare this 3 year old ticket as OBE and close it. |
IIRC @epage has used Renovate to send automated PRs to advance the |
Yah - rustup toolchain files are not a good fit for MSRV management; that belongs with cargo. |
Describe the problem you are trying to solve
In Rust-Embedded land, we are struggling with the management of our Minimum Supported Rust Version. That is, the promise we make to our users that compilers all the way back to our MSRV will compile this code, and we won't use any features stabilised after that compiler was released.
Currently we set an MSRV like a stake in the sand, and then time moves on and the stake gets further and further away. One of our crates has an MSRV of 1.30 - thats 72 weeks old at the time of writing. What I'd like to do is bring that MSRV along with us - trailing it behind us on a piece of string.
Describe the solution you'd like
Basically in my CI files I want to "rustup install stable-2", and if stable is 1.40, it would install 1.38. If stable was 1.51 it would install 1.49. Then I can set my Travis CI matrix to build on:
And I never have to touch the CI file again.
Notes
At the moment, to achieve a rolling MSRV we would have to touch the CI file every six weeks when there's a new stable release. That or
rustup install stable
, grok the current version with some grep/sed foo, subtract two minor versions (not easy in Bash) and then install that version.The text was updated successfully, but these errors were encountered: