包版本更新策略

Question

不确定这里是否是正确的提问地点，如果不是 - 请指出我正确的方向。

假设有一个包，为了现实世界的例子 - bind9。在 Precise 和 Quantal 中是 9.8.1 版。原始开发人员 (ISC) 当前提供版本 9.8.4，这是 9.8 系列中的错误修复版本，以及 9.9.2，这是一个“新功能”分支。看起来当遇到安全问题时，特定的错误修复被反向移植到 9.8.1。

现在的问题是：为什么维护人员不只是更新到最新的错误修复版本？为什么只向后移植某些补丁？是有意还是只是没有维护人员会努力更新到最新的错误修复版本？

Answer 1

Ubuntu 对此的政策在Wiki的稳定版本更新页面上有所描述。

这些政策都是由（完全合理的）担心引入回归并给现有用户带来不便，因为这些错误不会影响他们。如果 bind9 在稳定版本中更新，并且生产服务器因此出现故障或无法接受的行为改变，那么这对 Ubuntu 来说是一场灾难。用户会合理地抱怨稳定版本未能为他们保持稳定，许多人不会将“上游做了”视为合理的借口；特别是对于他们中的大多数人来说，无论如何都不需要进行错误修复更新。“不可接受的改变行为”对不同的用户可能意味着不同的事情；对于稳定版本，任何行为变化都可能被视为不可接受。

对稳定版本进行最少、可验证修复的 SRU 策略仅用于防止这种情况。

如果上游提供错误修复版本，则这些可以根据微发布例外政策在常设基础上批准接受。

但是 Ubuntu 中的大多数软件包都是基于 Debian 的。偏离 Debian 总是以额外工作为代价，因此这种改变只有在有人能够承诺维护由此产生的额外负担的情况下才能完成。

在稳定的发行团队，使个人的更新决定，以及技术委员会，使站在上发布微例外的决定。

或许 bind 的 bugfix release 分支适合微发布异常。在这种情况下，需要有人推动，收集上游政策，回归历史等，提出建议并提交给技术委员会审议。