包版本更新策略
不确定这是否是正确的地方，如果没有 – 请指出我正确的方向。
让我们说有一个包，为了现实世界的例子 – bind9。 在Precise和Quantal中它的版本是9.8.1。 原始开发人员（ISC）目前提供版本9.8.4，它是9.8行中的错误修复版本，9.9.2是“新function”分支。 看起来遇到安全问题时，特定的错误修正被反向移植到9.8.1中。
现在的问题是：为什么维护者不只是更新到最新的错误修复版本？ 为什么只向某些补丁移植？ 是故意还是只是没有维护者会花费更新到最新的错误修复版本？
Ubuntu的政策在Wiki的Stable Release Updates页面中有所描述。
这些政策都是由（非常合理）担心引入回归并对现有用户造成的不便之处造成的，这些错误不会影响他们。 如果在稳定版本中更新bind9并且生产服务器因此失败或无法接受地改变行为，则这对Ubuntu来说是一场灾难。 用户将合法地抱怨稳定的释放不能保持稳定，许多人不会认为“上游这样做”是一个合理的借口; 特别是对于大多数人来说，无论如何都不需要修复bugfix。 “不可接受的改变行为”对不同的用户来说意味着不同的东西; 对于稳定的释放，行为的任何改变都可能被认为是不可接受的。
针对稳定版本的最小，可validation修复的SRU策略仅用于防止此情况。
如果上游提供了错误修复版本，那么根据微发布例外政策 ，这些版本可以在常设的基础上批准接受。
但是Ubuntu中的大多数软件包都基于Debian。 脱离Debian总是以额外工作为代价，所以这种改变只有在有人能够承诺维持这种创造的额外负担时才能实现。
稳定版本团队针对个人更新做出决策， 技术委员会决定是否存在微观发布exception。
也许bind的bugfix release分支适用于微发布exception。 在这种情况下，有人需要开车，收集上游政策，回归历史等，汇总提案并提交技术委员会审议。