背景：2009 年 12 月，纽约市

当新成立的制作领导团队（PLT）于 2009 年 12 月在纽约市会面时，我们面临着一个挑战。尽管 Joomla! 版本 1.5 很受欢迎且成功，但它已经发布了近两年。版本 1.6 的代码包含了许多不完整且未经测试的功能，没有人能说版本 1.6 何时可能准备好发布。（结果是 2011 年 1 月，一年多以后。）

不用说，我们认为这种缓慢的发布节奏和不确定的未来对于项目或用户社区来说都不是一个好的情况。因此，我们决定制定一项计划来纠正目前的状况，并试图防止未来出现类似的情况。我们在那次会议上做出了两个关键决定：采用“稳定主干”实践和时间为基础的发布。

稳定主干

在软件版本控制术语中，主干（想象成一棵树）是用于发布程序版本的代码。开发者可以创建分支（主干代码的副本）来工作在主要更改上，如添加新功能。通过在分支中工作，一组开发者可以做出他们喜欢的所有更改，而不会影响主程序或在其他分支中工作的其他开发者。当一个功能经过测试并准备就绪时，该功能的分支将合并回主干，成为下一个版本的组成部分。

稳定主干的思路很简单：分支（想象成新功能）只有在完成、经过测试并准备好发布的情况下才合并回主干。这看起来简单明了，但在实践中可能会很困难。例如，一个功能可能“99%”准备就绪，“除了我们可以稍后修复的一些小问题之外”。合并它可能非常有诱惑力，特别是如果这个功能非常受欢迎，而且发布截止日期即将到来。收到消息说你在长时间工作的功能没有通过截止日期或没有被接受，这可不是什么有趣的事情。

维护稳定的总分支有哪些好处？其中之一是，多个开发团队可以在不同的分支上独立工作，有合理的保证，不会将半成品合并回总分支而破坏其他代码部分。这大大降低了由一个团队创建的更改对其他团队造成问题的可能性。另一个重要的好处是：如果您有一个稳定的总分支，您可以在任何时候发布版本，只需发布最新的总分支即可。这使得基于时间的发布成为可能。

基于时间的发布周期

正如丹麦物理学家尼尔斯·玻尔曾说过，“预测非常困难，尤其是关于未来的。”这当然适用于预测软件功能何时准备就绪。在像 Joomla 这样的志愿者驱动型开发项目中，这一点更为真实。在一家公司中，您通常知道可以投入多少人力完成一项任务。在 Joomla 中，我们不知道谁可能会做某项工作，也不知道他们可能有多少可用的时间或天数，更不用说他们何时能完成了。因此，准确预测新功能何时准备就绪发布是不可能的。

另一方面，有一个可预测的发布周期对社区来说有很大的好处。PLT 的解决方案是按照计划的时间表发布，但有重要条件：无法保证特定功能何时发布。例如，我们可以有信心预测我们将在 2012 年 9 月发布版本 3.0。但我们将不知道版本 3.0 将包含哪些新功能，直到它们完成并添加到代码库中。

短期支持（STS）和长期支持（LTS）发布

考虑到这些背景，让我们来看看当前 Joomla 发布周期的具体细节。在那次 2009 年的会议上，PLT 确定了一个雄心勃勃的目标——每六个月发布一个新版本的 Joomla。为什么发布这么频繁？一个重要的考虑是激励开发者。向项目贡献代码的志愿者希望看到他们的代码或功能被使用。如果发布之间的时间太长，我们就失去了这个激励因素。更频繁的发布也使得跟上 Joomla 所依赖的软件版本（如 PHP、MySQL 和 TinyMCE）变得更容易。所有这些程序都在不断发展和变化，我们需要能够跟上步伐。

为了实现这个雄心勃勃的目标，我们需要确保更新易于进行。例如，从版本 1.5 迁移到版本 1.6 是一项挑战。这主要是因为这两个版本之间有如此多的变化（三年之久的变更！）。另一方面，从版本 1.6 到 1.7 和从 1.7 到 2.5 的更新（我们希望！）相对顺利，我们正在努力使它们更好、更可靠。例如，版本 2.5 引入了自动更新通知，我们即将引入一个改进的更新引擎，它将在较慢的主机上运行得更可靠。

发布频繁版本也意味着我们需要注意向后兼容性。例如，与版本 1.6 一起工作的扩展程序也应该与 1.7 和 2.5 一起工作。

即使有更好的更新和良好的兼容性，PLT 也认识到六个月的发布周期对许多网站来说并不好。这就是为什么我们还在添加长期支持（LTS）发布的概念。例如，1.6 和 1.7 是标准短期支持（STS）发布，而 2.5 是长期支持（LTS）发布。这意味着版本 2.5 将至少得到支持，直到下一个 LTS 发布（版本 3.5）可用——目前计划于 2013 年 9 月发布。

因此，STS和LTS版本的概念非常简单。如果您想要最新的功能，应选择STS版本 - 例如，2012年9月的3.0版本，2013年3月的3.1版本，以及2013年9月的3.5版本。如果您想要稳定性和可以接受2.5版本的功能集，则保持在2.5版本直到3.5版本发布后，然后更新到3.5版本。对于4.0版本也是如此。选择4.0 / 4.1 / 4.5路径以获取最新功能，或者等待4.5版本以减少您需要进行的更新次数。

选择完全取决于您。唯一的要求是：如果您选择STS版本（例如3.0或3.1），您需要了解这些版本的生命周期较短，并且您实际上是在承诺每六个月更新一次，直到达到下一个LTS版本（例如3.5）。在此之后，您可以选择是否留在STS路径上（并选择4.0 / 4.1 / 4.5）或切换到LTS路径（并等待4.5版本）。

希望这能帮助您理解当前的发布周期。以下是常见问题解答。

常见问题解答

为什么我们跳过了1.7版本直接到2.5版本？

在2011年7月的一次会议上，PLT决定如果所有LTS版本都是X.5版本（1.5、2.5、3.5等），那么事情将会更简单。为了实现这个计划，我们可以（a）按照计划将2012年1月的版本称为1.8，并从版本2开始使用X.5编号；或者（b）我们可以从1.7跳到2.5，并将2.5作为下一个LTS版本。我们决定将此提交给社区投票，社区选择了（b）。因此，2012年1月的版本被命名为2.5，并且是当前的LTS版本。

为什么3.0版本计划在2012年9月发布，而不是7月？

在2.5版本发布过程中，有人建议12月对于许多人来说很难在发布前加班。经过大量讨论，决定将发布月份从7月/1月改为3月/9月。我们将继续按照六个月的时间表发布，但我们将进行一次性的调整来更改发布月份。因此，3.0版本计划在2012年9月发布，3.1版本在2013年3月发布，3.5版本在2013年9月发布。

版本1.5何时达到生命周期的结束？

最初的计划是在2012年4月结束1.5版本的生命周期。然而，许多人表示希望延长这个周期。从实际的角度来看，过去一年中1.5版本并没有需要很多更新，因此延长LTS周期预计不会需要大量的项目时间或资源。PLT尚未发布正式公告，但1.5版本的支持将持续到2012年4月之后 - 可能至少会持续到2012年9月。

从2.5版本到3.0版本的变化是否比从1.7版本到2.5版本的变化更大？

理论上，从2.5版本到3.0版本的变化可能比从1.7版本到2.5版本的变化更大。因为所有1.7用户都预期会立即更新到2.5版本，所以这个更新必须尽可能无缝、简单，并具有尽可能高的向后兼容性。对于2.5到3.0的更新，情况不同。2.5版本的用户可以选择在延长支持期间保持使用2.5版本（并最终更新到3.5版本）或更新到3.0版本。因为3.0版本的更新是可选的，因此在2.5版本和3.0版本之间进行可能需要迁移或某些扩展更改的变化有更多的灵活性。

在两种情况下，我们都希望使更新尽可能简单，并提供尽可能高的向后兼容性。从3.0到3.1，以及从3.1到3.5，我们将再次努力使更新完全无缝。然而，请记住，我们无法准确预测哪些功能将在3.0版本准备好，因此直到发布日期临近，我们也不知道变化有多大。

发布周期未来可以改变吗？

当前的发布周期并非“刻在石头上”的，未来可能会根据经验和社区反馈进行修改。一旦3.0版本发布，我们就将经历一个完整的STS和LTS发布周期。在那个时刻，评估其在实际中的表现并进行任何需要的修改可能是有意义的。