为何您应始终更新到最新的微版本！
我们经常被问到 Quarkus 维护者如何处理多个分支以及这对发布有什么影响。这篇短文旨在提供回答这些问题所需的必要信息。
开发分支
当维护者或贡献者想对 Quarkus 源代码进行更改时，会针对 main 分支打开一个拉取请求。这意味着一旦合并，所有更改都将成为 main 分支的一部分，并且不存在功能分支（这种做法有时被称为主干开发）。
main 分支上使用的 Maven 版本始终是 999-SNAPSHOT。 |
|
对于那些想为 Quarkus 做贡献但又不确定新更改应针对哪个分支的人来说，答案是明确的 |
新的主版本或次版本
作为简要提醒，Quarkus 始终为新的次版本或主版本提供至少一个候选发布版本（后者几乎总有多个此类发布）。这些发布使用 CR* 后缀，例如，3.11 发布的第一个候选发布是 3.11.CR1。
到了为新次版本制作新的候选发布版本的时候，会在 main 分支的头部创建一个使用主版本和次版本的新分支。例如，对于 3.11 版本，分支是在以下 HEAD 上创建的。
发布流程完成后，分支如下所示。
新的微版本
创建发布分支后，main 后续的所有更改都将针对未来的发布，除非它们被回溯到发布分支。
由于我们绝对希望发布分支包含来自 main 的最新错误修复，因此需要进行手动分类，以决定 main 中的哪些更改应被回溯到发布分支。Quarkus 的维护者在候选更改上使用 triage/backport* 标签。
到了发布新的微版本（或最终的 .0 版本）时，选定的更改会被手动回溯到分支。
main 中的新功能（除非有极少数例外）不会回溯到发布分支，因为我们希望发布分支尽可能稳定。 |
例如，对于 3.11.0 版本，分支如下所示。
将其与 3.11.0.CR1 的图像进行比较，您会发现只包含安全更改。
3.11.1 也是如此。
| 此回溯过程独立于每个支持的发布分支进行。这也是 GitHub 项目有多个回溯标签的原因。 |
结论
如果 Quarkus 用户应该从这篇文章中领悟一件事，那就是这个：
无论使用哪个 Quarkus 次版本，始终使用最新微版本都很重要。这样做的原因应该从这篇博文中显而易见，但值得再次强调：最新的微发布 - 称之为 .z - 几乎总是比 .0（或 .z 之前的任何版本）更稳定，因为它只包含错误修复，不包含新功能，因为新功能引入新错误的几率更高。
至于使用哪个 Quarkus 版本，这取决于以下问题：
我的项目更看重前沿功能还是稳定性？
如果答案是前者，那么应该使用 Maven Central 上最新的 Quarkus 版本。如果答案是后者，那么应该使用最新的 LTS Quarkus 版本。
