Clarify package upgrade policy.

[vadimcn]

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.

[vadimcn]

(obviously, this only applies to platforms, where installer packages are capable of enforcing such rules)

cc @brson, @alexcrichton, @pcwalton

[brson]

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.