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?

[kineticsquid]

Final comms with help from @amvanbaren and @croundy:

Open VSX Banner
Open VSX now supports deprecating extensions - see our announcement[link to blog below].

My Blog
New Feature in Open VSX: Deprecating Extensions

Open VSX, the only open source, vendor-neutral registry for VS Code extensions, now includes support for deprecating extensions—adding flexibility and transparency for both publishers and users. Previously, the only way for a publisher to retire an extension was to delete it from the registry, a rather abrupt approach that left users without notice.

With the new deprecation feature, publishers can mark an extension as deprecated, visually indicating its status to users while keeping it accessible in the registry. Publishers can choose to either allow continued downloads or restrict new downloads entirely. Additionally, they can direct users to a recommended replacement, offering a smoother transition path for users.

[imbed a screen cap of https://open-vsx.org/extension/msjsdiag/debugger-for-chrome]

This update reflects the Open VSX commitment to improving user experience and empowering extension publishers with more control over their content.

For information on how to request an extension to be deprecated, see our wiki[link to https://github.com/EclipseFdn/open-vsx.org/wiki/Managing-Extensions#deprecating-an-extension].

[kineticsquid]

https://blogs.eclipse.org/post/john-kellerman/new-feature-open-vsx-deprecating-extensions

[kineticsquid]

Banner update: #3076

[filiptronicek]

@kineticsquid: 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?

The neat part about the VS Code integration is that the only URL needed there is https://github.com/open-vsx/publish-extensions/raw/master/extension-control/extensions.json, which fork authors configure in the product.json file of their VS Code forks. After that, assuming they already use https://open-vsx.org for extensions, they're all set.

[kineticsquid]

@filiptronicek I think I'm asking a different question. I'm going to close this one as it was mostly about the comms. I've opened #3079 for the interface documentation.