Strategy for Handling Deprecated Extensions on EXO

Development
,
1

Hello,

There is a need to define a strategy for handling deprecated or unmaintained extensions on exo.

Deprecated extensions are extensions that are no longer maintained, have been superseded by another extension, or are incompatible with supported XWiki versions,.

There are already several extensions that fall into this category (e.g. XEclipse, XWiki Workspaces, Balsamiq, etc.), but they are currently listed altogether with active extensions. Some of them already display a warning box mentioning that they are deprecated, but others do not.

Some possible options to differentiate deprecated extensions from the other ones:

Option 1: Remove them completely

Delete the corresponding extension pages from EXO once an extension is considered deprecated.

Option 2: Keep them for historical purposes

Keep the extension pages, but clearly mark them as deprecated so that users understand they are no longer recommended.

One possible implementation would be to add a boolean property (e.g. deprecated ) to ExtensionCode.ExtensionClass , with a default value of false . When set to true , EXO could automatically display a warning banner such as: This extension is deprecated and is no longer maintained. It is kept for historical/reference purposes and is not recommended for new installations.

Option 3: Mark it as deprecated and then remove

Mark the extension as deprecated, display the warning banner, keep it visible for a defined period, and eventually remove it completely once users have had sufficient time to migrate.

I personally lean towards the lifecycle (option 3) rather than deleting extensions without being marked first. This would give us a consistent process for future cases as well. WYT?

Thanks!

2

Thanks @elenicojocariu !
I’m +1 for option 2 but with an additional improvement:

  • Make sure that extensions marked as deprecated have “Deprecated” in their title in the extension manager, otherwise admins might install them by accident (or at least won’t have an easy access to this information)
  • Plan an improvement of the extension manager to hide deprecated extensions by default
3

You are only mentionning EXO side here, and I’m fine with Option 2, but IMO the most important is what to do for Extension Manager since that’s where most users interact with extensions.

There are basically two possibilities:

a) Mark them as invalid (meaning that they won’t appear in Extension Manager at all anymore)

b) Make clear in the title that those extensions are deprecated (we don’t really have much other choice to make visible that they are deprecated for all the XWiki versions already released)
- bonus for later: introduce an actual “deprecated” metadata and display it as a marker instead of mangling with the extension name

Honestly I think a) is enough, there is no reason to keep listing those extensions to be installed. And we have Option 2 for not loosing historical data about those extensions (and for some of them maybe even put them back to life if needed).

4

I mistakenly thought this was already covered by the “Compatible with” checkbox in the Extension Manager, since when I searched for the examples I mentioned in the proposal, they weren’t displayed, but apparently indeed the XWiki Workspaces Application appear if you search for it.

So yes, I agree that both cases should be covered, marking deprecating extensions on exo but also in the Extension Manager. Thanks for pointing this!

5

Thx! From what I’ve seen, there are already a few extensions that have “[Deprecated]” in their title, both on EXO and in the Extension Manager.

Re option a) when you say “mark them as invalid”, is there an existing invalid property on extensions that will make the extension not listed at all in the EM?

6

Yes, the concept already exists, and the property ID is validExtension (in the UI, it shows up as the more pragmatic “Installable with Extension Manager” display name).

A listener is in charge of checking extension metadata at save and mark them valid (or not), only if they follow a list of requirements (mainly focusing on having downloadable version files) and only those extensions are then listed in the REST API. The idea would be to, once we have a new property to mark an extension as “deprecated”, to also take into account this in the listener (and so, mark as invalid an extension which is marked as deprecated).