Question

在支持具有扩展功能的多个TYPO3主要版本时，我正在寻找潜在的陷阱或最佳实践。有一些事情要考虑。

我注意到多个扩展在一个版本中支持多个TYPO3主要版本，例如

扩展版本1.0.0支持9.5。*和10.4。*

但是，这样一来，一旦弃用，您就无法真正摆脱掉。（例如，某个函数可能在10中被弃用，而有一个替换函数，但是在9中不可用，因此为了支持这两个函数，请使用已弃用的函数。）

这有一个缺点，即扩展扫描程序将指出许多不推荐使用的内容。我是扩展扫描程序的忠实拥护者，并尽快淘汰了旧版本。

创建扩展程序migration2composer时，我使用了单独的版本分支8.7。但是，如果我修复错误，则需要做更多的工作，因为它需要反向移植。

什么是好的策略？有什么方法可以使工作量最小？

Answer 1

在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);
    }
}

行// @extensionScannerIgnoreLine将使扩展程序扫描程序忽略下一行，并且不会使报告杂乱无章，请参阅Extension scanner documentation。

感谢Simon Gilli指出了这一点...

Answer 2

我为每个TYPO3 LTS版本发布了一个唯一的版本，以便能够丢弃旧内容。这也有助于自动化测试。

我就像您使用不同的分支来管理分支，并在它们之间进行樱桃选择式提交。

需要更多的工作，但是可以通过辅助脚本来简化。我在https://docs.typo3.org/p/dmind/cookieman/master/en-us/Contributors/Index.html#branches

上写了一些关于我们推理的句子

我听到一些用户对版本控制方案感到困惑，因此，事后看来，我下次选择使用1个主要版本= 1个TYPO3 LTS。

例如从

开始

v1 - TYPO3 v9
v2 - TYPO3 v10
v3 - TYPO3 v11

然后，如果我们的扩展程序有重大更改，请继续使用下一个免费的主要版本，也许会删除对较旧LTS的“新功能”支持。

v4 - TYPO3 v10
v5 - TYPO3 v11

但是，这也是一种折衷。这样，您不能说功能X是“版本> 4.1”，但将来可能会更好地理解作曲家方案，因此您可以说“ ^ 4.1 || ^ 5.1”。

在扩展中支持多个TYPO3版本的策略

2 个答案: