You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 21, 2018. It is now read-only.
It would be nice to formalize our package upgrade policy. In other words: When packages may be installed side-by-side, and when they are mutually exclusive?
A straw-man policy proposal, which seems to yield intuitively correct results: "The (target, channel, major, minor) tuple must be unique per-machine". Some examples of what this would mean:
Any 32-bit installation will co-exist with any 64-bit one (target is different).
Installing a nightly replaces previous day's nightly (they only differ in build revision).
Nightly, beta and stable with the same major.minor version will co-exist.
Installing 1.0-alpha.2 will uninstall 1.0-alpha.1. Installing 1.0-beta.1 uninstalls any 1.0-alpha. And so on...
1.0.x-stable will co-exist with 1.1.x-stable, but 1.0.1-stable will replace 1.0.0-stable.
The text was updated successfully, but these errors were encountered:
Any 32-bit installation will co-exist with any 64-bit one (target is different).
The windows and unix situations are different here in multiple ways: on windows installation naturally goes into its own directory, so multiple rustc's won't clobber each other. On windows we don't currently do cross-architecture compilation as easily as on unix.
My ideal is for any channel to have a single rustc installation that can target either architecture.
On Windows I agree this is ok.
Installing a nightly replaces previous day's nightly (they only differ in build revision).
Yes.
Nightly, beta and stable with the same major.minor version will co-exist.
I don't know how to do this on unix in a way that is ergonomic. Perhaps they could come with a tool that is like multirust-lite that swaps the active channel. Everything could be installed as e.g. rustc-1.0.0.
Installing 1.0-alpha.2 will uninstall 1.0-alpha.1. Installing 1.0-beta.1 uninstalls any 1.0-alpha. And so on...
Yes.
1.0.x-stable will co-exist with 1.1.x-stable, but 1.0.1-stable will replace 1.0.0-stable.
I have not considered this before, but it will definitely require some changes. Similar problems to the previous on unix.
It would be worth considering how various Linux package managers could support this.
I feel fine following the rules you've laid out on windows at least, though I want to think more about which stable compilers might coexist next to each other.
They are harder to support on unix, but on unix it's common to see multiple versions of e.g. gcc installed together. Distros will probably want it eventually, so we should figure out how to do it.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It would be nice to formalize our package upgrade policy. In other words: When packages may be installed side-by-side, and when they are mutually exclusive?
A straw-man policy proposal, which seems to yield intuitively correct results: "The
(target, channel, major, minor)
tuple must be unique per-machine". Some examples of what this would mean:major.minor
version will co-exist.The text was updated successfully, but these errors were encountered: