滚动发布如何工作？

Question

根据我对 linux 发行版的理解，您会收到更新通知，然后只需单击一下或使用一堆命令就可以安装它们。这些可能是您之前安装的软件的补丁或次要版本更新。例如，发行版可能会建议将 Firefox 版本 23 升级到 Firefox 版本 24（不好的例子，这不是次要版本，但您明白了）。但是，几个月后，系统会要求您进行升级：您正在更新系统本身，而不是您已安装的软件包。

为什么系统本身不能像其他软件包一样通过小的、持续的更新来更新？

滚动发布使用什么解决方案来解决这个问题？

Answer 1

为什么系统本身不能像其他软件包一样通过小的、持续的更新来更新？

它可以，因为您注意到某些发行版确实以这种方式工作。升级的过程本质上是一组更新；“更新系统本身”之间的区别的，“不，你已经安装了软件包”有点不确切，因为系统是您已经安装了刚刚软件包。各种发行版可能有一些仅适用于升级的明确标准，但我认为这不是使用这种方法的原因。我认为使用版本升级根本没有任何特定的技术原因，而且我怀疑传统的版本控制发行版转换为滚动发布是否需要很多。

我认为主要原因是划分。某些东西的第 2 版可能需要对第 1 版进行重大更改，而这不能仅通过一系列可逆的调整来完成。因此，当您在使用版本 2 时，可能需要继续维护不适用于版本 2 的版本 1。几乎所有实际软件都是以这种方式完成的。AFAIK，它只是使用滚动发布模型的软件发行版。

此外，如果 V.2 最初被证明是一场惨败，用户会喜欢使用以前的版本，这种逻辑当然适用于 linux 发行版。

滚动发布使用什么解决方案来解决这个问题？

好吧，他们对软件包使用版本控制。这很好，因为如上所述，系统只是包。没有安装任何不属于包的东西，所以修改系统只是集体更改一些包的问题。

对于版本化发行版，包实际上有两个相关联的版本，包版本和发行版。例如，您会找到whatever.1.2.3用于发行版的多个并发版本的软件包。我想象这提供了相当多的灵活性，而不是我所说的发行版之间的“重大变化”。What1.2.3 可能来自同一个上游（原始）源，但在发行版 2 中配置不同，以反映对版本 1 的重大架构更改。