背景：2009年12月，纽约市

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

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

稳定主干

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

稳定主干的思路很简单：一个分支（想象成新功能）只有在它完整、经过测试并准备好发布时才会合并回主干。这看起来很简单和明显，但在实践中可能很困难。例如，一个功能可能“99%”准备就绪“除了我们可以稍后修复的几个小问题”。合并它可能非常诱人，尤其是如果这个功能非常受欢迎，而且发布截止日期临近。当你收到你长时间工作的功能未能通过截止或未被接受的消息时，这并不好玩。

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

基于时间的发布周期

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

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

短周期和长周期发布

考虑到这个背景，让我们看看当前 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也是如此。走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版本）。

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

常见问题（FAQ）

为什么我们跳过了版本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发布周期。那时，评估其实际效果并做出任何所需改变可能是有意义的。