README: Add deprecation notice

[machty]

Given the number of Ember/Glimmer-related extensions on Github + VSCode marketplace (and how much confusion it can cause for the community), I'm doing some work to try and clean things up and move users to Stable Ember Language Server and/or Glint

Would you be open to:

1. Merging this PR
2. Archiving this repo
3. Marking the published extension as deprecated (this has already been done!)

Thank you in advance!

[evoactivity]

I'd like to actually merge @lifeart's fork back here and consolodate all tooling back into this org. There was opposition to doing this previously from LinkedIn I believe, but there has been no activity here from them and this repo is now stale and unmaintained.

@lifeart do you have any objections to doing this in principle?

[machty]

Would that also mean undeprecating this repo's extension?

[NullVoxPopuli]

I'm very shocked by these numbers:

all 55k of these folks should be using the same language server :sweat_smile:

[evoactivity]

Would that also mean undeprecating this repo's extension?

Probably. Hopefully.

The deprecation of the extension shows up inside vscode, but not the extension marketplace https://marketplace.visualstudio.com/items?itemName=EmberTooling.vscode-ember

It's quite confusing, I don't actually understand how it's marked as deprecated at all.

The 0.2.1 version was never pushed up to the repo either. So I think someone with publishing permisions did that maually a while ago and never commited the changes to the package.json that marked it deprecated.

[evoactivity]

A strategy I think we would use would be.

1) Merge back ember-language-server from lifeart's fork to this repo 2) Merge back vscode-ember from lifeart's fork to the version in this org 3) Update lifeart's vscode-ember addon to be an extension pack that installs the ember-tooling version 4) Publish updates to VSCode Marketplace and OpenVSX under the ember tooling orgs 5) After 6 months or so unpublish lifearts forks from the marketplaces

• I don't think a complete PR review is necessary at this point. Lifeart's work has proven stable and is battle tested. Any merge conflicts I'd say just accept the new changes.

[lifeart]

@evoactivity no objections, I'm in!

One note here: I believe we need some space for experiments without hurting ecosystem stability (and after merging my fork, instead of unpublishing, I would rename it to Experimental / Nightly and update logo to more neutral)

Before introducing some significant changes into LS, we could ask enthusiastic developers to try in Experimental extension, and once stable - we could land it for whole community.

[evoactivity]

@lifeart that makes sense, we could do pre-release extensions for this though https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

I found where the deprecation occured. Locks requested it in this thread https://github.com/microsoft/vscode-discussions/discussions/1#discussioncomment-3231983. I hope un-deprecating can be done similarly. I've asked if it's possible to undeprecate https://github.com/microsoft/vscode-discussions/discussions/1#discussioncomment-8433155

[evoactivity]

I've had confirmation we will be able to undeprecate the extension. So we can move forward with creating the PR's and merging.

One downside to the above strategy is we will lose the current issues from lifearts repos. We could use https://github.com/gatewayapps/kamino chrome extension to clone the issues into this repo though.

[lifeart]

@evoactivity it seems that it may be easier to remove all using one commit (here), and create PR to blank repo. Issues, from fork we may list in one new here under checkbox-list, with reference to original

[evoactivity]

Just to be sure, do mean we should create a commit that deletes all the current files/folders of this repo, then creating a PR from your fork so we avoid all the merge conflicts?

That makes sense to me. We keep the git history and avoid a bunch of annoying merge conflict work.

[lifeart]

@evoactivity yep (this is how it seems simplest way to deal with it), we still have history, no side-effects and conflicts

[evoactivity]

@lifeart ready for your PR's to this repo and vscode-ember 🎉

[lifeart]

@evoactivity PR's created:

https://github.com/ember-tooling/vscode-ember/pull/36 https://github.com/ember-tooling/ember-language-server/pull/387

But it seems we need to figure out way to no resolve conflicts for all commits :)

[machty]

FYI the original VSCode ELS extension has been undeprecated in the last 24 hours.

I can confirm it is showing undeprecated in VSCode:

Did we ever publish a new VSCode extension for the undeprecated ELS? Looks like last release was 2020.

[evoactivity]

I'm aware :)

I'll be releasing everything tomorrow hopefully, or the weekend most likely.

[machty]

I've switched to the ember-tooling ELS and everything's working well.

What's the next steps? Deprecate UELS and drive traffic to ELS?

[evoactivity]

Yep, that's the plan but need to know if @lifeart is happy with that as he'll need to handle that. I know he feels there should be an extension that can be used for experimentation but my feeling would be for any "official" experiments we use the pre-release feature. People can choose which version they install from the official extension. For community experiments people can publish other extensions if they wish.

The idea would be to publish a final update to UELS that will delete everything and install ELS as an extension pack and after some time (maybe 3 to 6 months deprecate the extension entirely).

In the meantime I will update the official extension pack to install ELS so we should be able to get a lot of people moved over with that update.

[evoactivity]

The extension pack has been updated to install this version of the language server.