Strategies for supporting multiple TYPO3 versions in extensions - typo3

Question

I am looking for potential pitfalls or best practices when supporting multiple TYPO3 major versions with extensions. There are some things to consider.
I noticed several extensions support several TYPO3 major version in one version, e.g.
extension version 1.0.0 supports 9.5.* and 10.4.*
However, this way, you can't really get rid of things as soon as they are deprecated. (For example, a function may be deprecated in 10 and there is a replacement function, but this is not available in 9, so in order to support both you use the deprecated function).
This has the disadvantage, that the extension scanner will point out lots of things which are just deprecated. I am a huge fan of the extension scanner and getting rid of deprecations as soon as possible.
When I created my extension migrate2composer I used a separate version branch 8.7. But this is more work if I fix bugs because it needs to be backported.
What is a good strategy and are there ways to keep the workload minimal?

Answer 1

One possibility to support multiple versions and already use the new functionality can be found in the bootstrap_package:
/***************
* Make the extension configuration accessible
*/
if (class_exists(\TYPO3\CMS\Core\Configuration\ExtensionConfiguration::class)) {
$extensionConfiguration = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(
\TYPO3\CMS\Core\Configuration\ExtensionConfiguration::class
);
$bootstrapPackageConfiguration = $extensionConfiguration->get('bootstrap_package');
} else {
// Fallback for CMS8
// #extensionScannerIgnoreLine
$bootstrapPackageConfiguration = $GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['bootstrap_package'];
if (!is_array($bootstrapPackageConfiguration)) {
$bootstrapPackageConfiguration = unserialize($bootstrapPackageConfiguration);
}
}
The line // #extensionScannerIgnoreLine will make the extension scanner ignore the following line and will not clutter up the report with this, see Extension scanner documentation.
Thanks goes to Simon Gilli for pointing this out ...

Answer 2

I release a unique version for each TYPO3 LTS version to be able to throw out old stuff. This also facilitates automated testing.
I am like you using different branches to manage that and cherry-pick commits between them.
It's a little bit more work but can be facilitated with helper scripts. I have written some sentences about our reasoning here https://docs.typo3.org/p/dmind/cookieman/master/en-us/Contributors/Index.html#branches
I've heard from some users being confused by the versioning scheme, so in hindsight for the next time I would choose to stick with 1 major version = 1 TYPO3 LTS.
E.g. starting with
v1 - TYPO3 v9
v2 - TYPO3 v10
v3 - TYPO3 v11
And then if our extension has breaking changes, continue with the next free major version, maybe removing the "new feature" support for an older LTS.
v4 - TYPO3 v10
v5 - TYPO3 v11
It is also a compromise however. This way you cannot say that feature X is "in version > 4.1" but maybe the composer scheme will be better understood in the future so you could say "^4.1 || ^5.1".