Define status for APIs which are not intended to be included in core

[jobisoft]

To reduce the number of repositories, I want to sunset the addon-developer-support repository and provide the information elsewhere (directly in the documentation, on DTN, and here). I would like to move these APIs into this repo:

https://github.com/thunderbird/addon-developer-support/tree/master/auxiliary-apis

Some of those APIs are not necessarily intended to be added to core, or at least at this state we have no intention. What status should they get? The "draft" status might give the wrong expectation, that it is intended to be included?

[kewisch]

If you are not intending for them to be in core, you could also consider not adding them at all. I'm guessing your intent is to have these as a resource for current developers to fill the gaps to what was possible before, but make it easier to transition to WebExtensions. If they can't actually use these APIs some time in the future, this buys them another reliance they need to get rid of eventually. Not having them is a hard break, and they might be writing the same code on their own if they don't fully believe in WebExtensions, but it could also force them to think about how their add-on might fit into the concept of WebExtensions and use APIs that are more viable for core.

If you'd still like to keep them, maybe something like "Informational" or "Not on Core Track" (I'm thinking about the parallels to the IETF standards track), or simple "Not intended for inclusion in core", to spell out very clearly.

[jobisoft]

We might find different ways to make the functionality available later, for example we could allow prefs to be set through a thunderbird_settings API. Once that is implemenyed and the pref they need is accessible, they can switch.

The goal of these APIs is that I maintain them for them, to minimize the update burden for them.

But yes, that is the question we have to solve, if these APIs should be added here, or if we should keep them in a different resource repository and make this repo only about APIs which have the clear intent to be merged into core.

[jobisoft]

I re-launched the add-on-developer-support repo as https://github.com/thunderbird/webext-support

It no longer contains the stuff I created 4 years ago to help developers to wrap their legacy extension inside an Experiment (the WindowListener API, currently still ~20 add-ons using it, getting less every year), but is now a simple repo with additional resources.

I originally wanted to get rid of it entirely, but based on your feedback, I went ahead and prepared it to keep hosting the mentioned APIs. I guess this is what you would like to see, instead of merging them here?

[kewisch]

I don't mind you merging them here, it doesn't make a difference if it is in webext-support vs webext-experiments. In both cases they are "official" in the thunderbird org. My point was rather, would you consider sunsetting them and simply not offering them in any repo, so that new add-ons aren't tempted to use them? Remaining consumers will be able to use them because they have the code in their codebase already. But if add-ons should be getting rid of this code, we shouldn't make it easy for them to include/maintain it.

That said, I haven't taken a close look at each of those APIs, and you have a better overview on their purpose. If you want to separate it out, you could have an /unsupported/ subdirectory in this repo which clearly spells out in a README.md how to (not) deal with those APIs.

[jobisoft]

My point was rather, would you consider sunsetting them and simply not offering them in any repo.

I do want to keep them. I track their usage and help removing them, I also guide to alternatives. But some add-ons will die if they cannot use these APIs and in these case I want to provide them to lower the maintenance burden until the functionality is available through a WebExtension API.

I will keep webext-support and not merge them here.