Cross-release collaboration

[ConradIrwin]

Check for existing issues

• [X] Completed

Describe the feature

Goal:

• Users can collaborate without regard for which release stage we’re on (for the most part). Constraints:
• We’re going to keep deploying one collab server per release stage for now, to keep velocity high.
• We’re going to accept some risk of the experience not being perfect when collaborating between release stages, as long as it mostly works most of the time.

Changes:

• By default nightly will talk to nightly collab, which will use the staging database and be distinct from preview and staging.

• We’ll add a setting to let you specify which collab server to talk to in nightly, so you can override this to use nightly to talk to the preview collab server (which will let you collaborate with anyone on preview or stable).

• We’ll stop breaking things at the protocol level, so that we can send “invalid” protocols to older versions without breaking things (and add a linter to protect against this)

• We’ll add a new mechanism for out-of-date client detection so that we can still force clients to update when necessary.

• We’ll proxy protobuf messages between preview and stable so that those two environments can collaborate together easily using redis PUB/SUB.

• Stretch: We’ll show a warning to anyone using preview (or nightly) to collaborate with someone on stable that there might be oddities.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[maxdeviant]

• By default nightly will talk to nightly collab, which will use the staging database and be distinct from preview and staging.
• We’ll add a setting to let you specify which collab server to talk to in nightly, so you can override this to use nightly to talk to the preview collab server (which will let you collaborate with anyone on preview or stable).

I still think I'd like to see this flipped, so that Nightly, by default, connects to the same collab server as the other channels. I guess it depends on how often we plan on using Nightly as a regular client (e.g., in day-to-day usage) vs just when testing something (which is the only reason I see for connecting to the staging database).

That being said, if this is a permanent setting (so I don't have to remember to launch Nightly with a particular environment variable each time, for instance), I don't think it makes too much of a difference.

[ConradIrwin]

Updates having spent a bit of time looking into this approach, and talking with @nathansobo and @maxbrunsfeld.

It turns out the Redis idea is not quite trivial because we rely on RPC clients to be able to respond to messages sent from the server. This is solvable by tracking more data in the envelope, but quite a deep cut.

It also doesn't resolve the residual concern of "some weirdness", and so may be more effort than it's worth:

Instead:

• [x] We'll add the ability for per-release stage settings
• [x] We'll make server_url a setting.
• [x] Nightly will continue to default to https://zed.dev, but we can set it to https://staging.zed.dev as needed. (stretch goal would be to add a command to do this, but not yet).
• [x] We'll reduce the number of server-side environments down to two:
• [x] https://zed.dev and https://collab.zed.dev will be "production"
• [x] https://staging.zed.dev and https://collab-staging.zed.dev will be "staging"
• [x] We'll stop making backward incompatible protobuf changes (and lint for this)
• [x] We'll start sending the app version as part of the handshake so we can still force upgrade old versions as necessary.

[ConradIrwin]

With https://github.com/zed-industries/zed/pull/7130, this is all done (Except the command to switch to staging easily).