问题描述
为什么官方Ubuntu版本库中的软件包比Debian Sid，PPA和作者等的最新版本(上游版本)早？
最佳解决办法
一个Ubuntu发行版经过了几个阶段才将其作为成品发布给公众：
-
在Ubuntu发布之前的一段时间，它会在某个时候冻结其软件包。
-
在发布发布之前，但在发布包冻结之后，工作主要是为了修复这些包中可能存在的所有错误和问题。封装或功能冻结后，新软件包版本不再导入存储库。
-
一旦发布发布，对这些软件包的其他更改只会发生在修复错误和安全问题上。即使发布新版本的软件包，官方存储库中的软件包也不会再进行升级。
新版本的软件包一直从Debian推出，用于下一个Ubuntu版本，直到下一次冻结发生并且相同的过程重复。
作为一个例子，你可以看看release schedule of 12.04。
你可以看到，尽管4月份发布了12.04，但在1月12日发生了一件名为Debian Import Freeze的事情。
这只是实际发布之前发生的许多冻结阶段中的第一个，并且意味着此时从Debian测试或不稳定停止导入软件包并开始工作，开始自定义和解决与它们有关的问题。
在许多软件包中没有任何升级之后，软件包所具有的版本就是版本的存在，并在发行版的整个生命周期内进行维护。
因此，即使开发人员的PPA或Ubuntu + 1存储库中存在更高版本的相同软件包，这些软件包也只会包含在Ubuntu的下一个版本中。
这是为了稳定性，安全性和功能性。一直导入到主要存储库的新出血包将意味着问题以及更多需要解决的问题。包版本中的冻结有助于对此进行分类并使Ubuntu对最终用户更安全和更稳定。
新版本的Ubuntu每6个月发布一次，因此每6个月会为新版本准备，测试，定制和发布新包。未来版本的软件包可以通过PPA安装在您的系统中，也可以从网站上下载，但官方软件库中的软件包版本保持不变。
有关Ubuntu 10.04到12.04发布的详细信息和有趣概述，请参阅ReleaseSchedule - LTS to LTS和Stable Release Updates page，以获取有关Ubuntu稳定版的完整概述和说明。
次佳解决办法
两个原因。第一个是非常明显的：它需要一个人在新的上游出现时花时间更新包装。第二，如果您正在运行稳定的版本而不是当前的开发版本，那么软件包有意不更新willly-nilly以避免损坏。参见http://wiki.ubuntu.com/StableReleaseUpdates。
第三种解决办法
由于许多原因，软件包因发布而被冻结并且未被更新。如果新版本被引入post-release，那么新版本……
-
可能会带来新的错误，从而降低发布时的功能
-
需要人工进行打包，测试和上传
-
需要自己的一套安全更新
-
将需要为其用户界面更新翻译
-
需要更新文档(和翻译)
-
使技术支持更具挑战性
-
可能会让已经习惯了旧版本功能的用户感到厌烦
-
可能需要更新的依赖关系，如果在存储库中更改了其他应用程序，则可能会破坏其他应用程序
-
可能会打破依赖于此的其他软件包
-
可能会中断为旧版本创建的用户脚本，模板，工具等
所有这一切，请注意，在某些情况下，Ubuntu会在存储库中完全更新软件版本。例如Firefox。
此外，还有一个ubuntu-backports存储库，用户可以选择将哪些更新软件包引入到上面列出的问题中。它没有默认启用，所以用户必须使用opt-in，这样做是为了消除软件从你下面更换的惊喜。另外，它的人员并不多，所以我不确定包的实际更新频率。
此外，SRU团队最近更新了一些策略，希望能够让它更容易获得bugfix-only软件包更新。
第四种办法
我会尝试根据我以前在Ubuntu论坛和Ubuntu Planet上的经验回答你的问题。
我想我只是想知道apt存储库如何更新以及由谁来更新。
APT回购确实从Ubuntu的包装团队获得更新。包装团队从开始进行初始包装测试和其他事情的开发人员处获取所有上游软件包。然后测试团队进行最后的测试，发出一个信号。但是包装团队和测试团队对依赖关系及其对稳定系统的影响非常谨慎。
当存在滞后时，是否因为开发人员没有将最新版本推送到相关服务器上？
如果你看到上游的变化，有成千上万的开发人员想要推送他们的软件包。但并非所有人都成功进入主流，这是因为各种原因。假设Gedit应用程序，一个2.2版本适用于Dbus 2.1和Gtk 2.4等，而Gedit 2.4版本(非常新)需要Gtk 2.5和Dbus2.3才能正常工作。现在测试和打包团队(发布团队也不接受这个)，因为改变一个具有旧dbus和gtk的现有系统与新的打破了一切。希望你得到了依赖地狱的点。
开发人员在将版本发布到存储库可以使用的表单中是否还有更多工作要做？
不是上游渠道。但是发布频道是:)。
P.S：与上面解释的相比，规范中的过程可能会发生一些变化。但它或多或少一样。
第五种办法
通常，Ubuntu发行版中的更新是为了安全性和错误修复，此类错误的示例包括：
-
错误可能会在实际情况下直接导致安全漏洞。这些由安全团队完成，并记录在SecurityTeam /UpdateProcedures中。
-
代表以前版本Ubuntu严重衰退的错误。这包括完全不可用的软件包，例如在启动时可以卸载或崩溃。
-
在实际情况下可能会直接导致用户数据丢失的错误不符合上述类别的错误，但(1)具有明显安全的修补程序，(2)影响应用程序而不是关键基础结构软件包(如X.org或内核)。
-
对于长期支持版本，我们经常希望启用新的硬件。只要我们确保不会影响现有硬件的升级，这些更改就是合适的。例如，新引入的驱动程序的模式不得与先前发布的驱动程序重叠。 – Canonical合作伙伴存档中的新版商业软件。 -FTBFS(无法从源构建)也可以考虑。请注意，主版本过程确保没有不是从当前源构建的二进制文件。通常这些错误应该只与另一个错误修复一起使用。 – 对于提供新功能的新上游版本的软件包，但不修复重要的错误，应该请求反向端口。
采取从优秀维基页面StableReleaseUpdates。
第六种办法
在链接fossfreedom公布的评论接受的答案是非常好的。
通常，在新版本开发过程的第一部分之后发布的软件包版本不会出现在该版本的主版本库中，因此可以对可靠的Ubuntu版本进行彻底测试。
你可能会发现一些软件包被发布到backports存储库，如果它们被成功地整合到未来的Ubuntu发行版中，并且开发人员认为这些软件包也可以与早期版本一起使用。 Backports可以在软件中心激活和停用(Edit-> Software Sources-> Updates Tab-> Unsupported Updates)