Post about RLS deprecation.

[ehuss]

This adds a post announcing the deprecation of RLS.

cc @rust-lang/devtools @Xanewok

cc @rust-lang/release You have been dealing with the brunt of fixing RLS builds. Are you OK with the timeline proposed here? This would mean keeping it running for two more cycles (the current 1.63 and 1.64).

Specific timelines and details for additional steps (like marking the vscode extension as deprecated) will be decided later.

[Mark-Simulacrum]

From a release perspective I think two cycles should be OK. As of the last release, we have now vendored racer into the RLS tree, which helps reduce the burden of upgrades considerably (since we no longer need to coordinate as many repositories and crates.io releases).

(I think we could reasonably extend further, though I don't see any reason to at this time: ultimately RLS isn't getting new development at this point).

[aminya]

What happens to the open PRs? I saw people merging racer into RLS in a couple of hours without any notice, while there were a couple of open that fixed various things. It seems that the decisions related to a project are made somewhere other than the repository itself without any notice.

[bjorn3]

I saw people merging racer into RLS in a couple of hours without any notice, while there were a couple of open that fixed various things. It seems that the decisions related to a project are made somewhere other than the repository itself without any notice.

See around https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/release.201.2E61.2E0/near/282578859 for the merge of racer into RLS. Other than keeping RLS compiling (which this merge makes much easier) there is effectively no development done on RLS anymore AFAICT.

[calebcartwright]

What happens to the open PRs? I saw people merging racer into RLS in a couple of hours without any notice, while there were a couple of open that fixed various things. It seems that the decisions related to a project are made somewhere other than the repository itself without any notice.

@bjorn3 is correct on this @aminya. Both Racer and RLS have been in maintenance mode for quite some time, and typically only had changes merged when absolutely required to fixing breaking issues. There's a complex dependency relationship and build story between those and such breakage often causes upstream problems.

The maintainers of both of those projects haven't really had much bandwidth for them (especially in their maintenance/deprecated state), so the merges you are referencing were strictly to make it easier for the team to address those breaking issues without having to coordinate across multiple projects and maintainerships.

These are steps that are strictly about making it easier to proverbially "keep the lights on", and it's not about picking some PRs over others.

[pietroalbini]

@aminya to expand on what the others said, the reason some PRs are created and merged really quickly is because they're blocking Rust releases from being published, and the Release Team steps in and creates/merges them to be able to continue with the release process.

RLS calls internal APIs of both Cargo and the Rust compiler, so refactorings in either codebase can result in RLS failing to build. While on nightly that's not a problem (in those cases RLS is simply omitted from that nightly release), the beta or stable toolchains won't be valid without a working RLS build, forcing the Release Team to intervene.

[Xanewok]

Sorry for the lag on everything RLS-related, I feel burnt out and feel like I never really closed off this chapter properly. Thanks for all the work on this and let me know if I can help more in this case.

On the rls binary note, maybe we can just symlink it to the rust-analyzer and call it a day? We didn't ever guarantee the stability of RLS and it's using literally the same protocol to communicate with IDEs.

[bjorn3]

Rustup doesn't support symlinks AFAIK, nor does windows support symlinks in many configurations. A wrapper executable would be possible though.

[ehuss]

@Xanewok Please don't feel obligated or pressured on anything here. I think everyone is super grateful for the effort you put in. I know you were the last one left maintaining RLS, and that was probably not a good situation.

I'm uncertain if pointing rls to rust-analyzer would work or not. I did a little test locally, and it seemed to mostly be ok, with a few rough edges. I was concerned about the workspace config loading, but it looks like rust-analyzer ignores any unknown fields. The other issue is that rust-analyzer is on the nightly channel only, so rust-lang/rust-analyzer#12432 might block that approach. It's definitely worth considering, though.

[Xanewok]

Can I go ahead and mark the VSCode extension as deprecated (as is implemented in VSCode 1.68) or do we want to wait for the blog post (and stable toolchains)?

[tmandry]

If we're talking about the official extension it might be nice to have some sort of announcement to point to in the deprecation notice, but then we could always point to one of the earlier blog posts about rust-analyzer.

[ehuss]

I updated the date to tomorrow (07-01). @rust-lang/release if you're OK with that, I think this is ready to merge and could probably go out tomorrow.