Comms for support of deprecated extensions

[kineticsquid]

We need to prepare communications to go along with the support for deprecated extensions in #1121. To wit,

• Banner update
• Documentation explaining how to deprecate an extension and what's in the extensions.json file. I'm thinking a page in the wiki linked to from the main doc page: https://github.com/eclipse/openvsx/wiki.
• Blog
• Email to mailings

[kineticsquid]

• Suggested message for banner: "Hey, we've added support for deprecating extensions. Details here [link]."
• Wiki updates: https://github.com/kineticsquid/open-vsx.org/wiki
• Email text

Subject: Open-vsx.org adds support for deprecating published extensions
Body:
With release x.y.x, we've added support to allow a publisher to mark their extension(s) as deprecated. Deprecated extensions are marked in the UI. Publishers have the ability to disallow or continue to allow installations. They can also opt to point to a replacement extensions. More details here [link].

• Blog:

With release x.y.x, we've added support to allow a publisher to mark their extension(s) as deprecated. Deprecated extensions are marked in the UI with ....
[image]
Publishers have the ability to disallow or continue to allow installations. They can also opt to point to a replacement extensions.
[image]
The open-vsx.org API now returns deprecated information with an extension's metadata [swagger link].

We've also updated our wiki [link] with instructions for publishers.

[filiptronicek]

Thanks for drafting those up @kineticsquid, including the Wiki page, they look great. Should we also mention on the wiki that the extension-control/extensions.json file is also responsible for flagging malicious extensions? Additionally, I'd love to see a section about the VS Code integration, because although it's not user facing or configurable, participating forks such as the one Gitpod uses use the manifest to inform users about deprecated extensions and makes it easy to migrate to supported alternatives with a single click.

[kineticsquid]

@filiptronicek Re malicious extensions. I thought about that but decided to not include it because we, thankfully, don't have any yet. I think when we'll add it and document it then.

I'm all for robust documentation and I certainly don't mind drafting pages for the wiki. Are you talking about documenting calls like @amvanbaren discusses in eclipse/openvsx#432? Or something else?

[filiptronicek]

@kineticsquid

@filiptronicek Re malicious extensions. I thought about that but decided to not include it because we, thankfully, don't have any yet. I think when we'll add it and document it then.

Sounds good, let's add them then.

I'm all for robust documentation and I certainly don't mind drafting pages for the wiki. Are you talking about documenting calls like amvanbaren discusses in eclipse/openvsx#432? Or something else?

I am talking about the native integration in VS Code, as shown in the screenshots on microsoft/vscode-discussions#1 (comment). It's what Microsoft does with its list and what participating forks (which AFAIK is only Gitpod's at the moment) use to suggest alternatives to deprecated extensions and uninstall malicious ones.

[kineticsquid]

@filiptronicek What's the best way to get a full list of the URLs needed for this integration, that are not part of our document API?

[kineticsquid]

@filiptronicek Let's take what you describe above in #2750 (comment) to a separate enhancement request in https://github.com/eclipse/openvsx. Is this just a documentation effort, or are there enhancements we need to make?