GTK+ 的版本控制和长期稳定性承诺

本文中提出的计划取代了 2016 年 6 月多伦多 GTK+ 黑客马拉松之后公开的计划。

本月,GTK+ 团队将发布一系列长期稳定版本的第一个版本。这将使 GTK+ 更具可预测性和可靠性,同时不会妨碍 GTK+ 未来的改进。

这些计划是自去年 6 月在多伦多举行的 GTK+ 黑客马拉松上制定初步计划以来,与各利益相关者讨论的结果。

背景

自 2002 年发布 2.0 版本以来,GTK+ 一直遵循相当简单的版本控制方案

  • 主版本号指定通用 API 版本
  • 次版本号指定开发周期(如果为奇数)和稳定周期(如果为偶数)
  • 微版本号指定错误修复更新

任何在 GTK+ 中引入的 API 都保证在下一个主版本之前存在;在开发周期中引入的 API 保证在稳定周期开始后保留。稳定周期不提供新功能或新 API。

该方案为我们提供了良好的服务,但其问题在 3.x 系列中变得越来越明显,尤其是在与 6 个月、基于时间的开发周期相结合时。在 2.x 周期中,GNOME 应用程序的新功能被迫出现在其他库中,因为工具包太复杂或移动太慢。自 3.0 以来,GTK+ 的开发速度一直在加快。GTK+ 已被置于中心位置,每六个月都会引入新的小部件和新功能。但是,为了实现这些新的小部件和功能,工具包的一些内部结构一直处于变化状态。

从 GNOME 的角度来看,GTK+ 一直是一个相当稳定,但不断变化的目标,因为 GNOME 开发人员和 GTK+ 开发人员可以共享反馈和建议,并快速跟上内部变化。另一方面,从社区的角度来看,跟踪 GTK+ 的开发更加痛苦。GNOME 项目之外的应用程序开发人员很难了解工具包中的哪些更改会影响他们的代码库。GTK+ 团队试图改进其沟通渠道,但在开发周期中发布有关更改的博客对于更广泛的 GTK+ 用户社区中的许多人来说还不够。

长期稳定的 GTK+ 版本

GTK+ 有三个主要利益相关者:想要功能和 API 稳定版本的应用程序开发人员;想要访问 GTK+ 开发版本以便快速引入新功能的桌面开发人员(这包括大多数 GNOME 项目);以及 GTK+ 团队本身,他们需要在较长的开发周期中迭代库的内部结构。

引入长期稳定的 GTK+ 版本旨在确保 GTK+ 在每个受众之间取得良好的平衡。特别是,应用程序开发人员将可以访问一个稳定的平台,该平台仍然可以访问在 3.x 系列中开发的新 GTK+ 功能,例如 CSS 样式、触摸屏支持、HiDPI 显示支持、Wayland 支持、新的小部件、GTK+ 检查器等。

GTK+ 将继续发布主版本、次版本和微版本。一旦新功能稳定下来,就会发布新的主版本,预计大约每 2-3 年发布一次。当升级到新的主版本时,将删除已弃用的 API。之后,此 API 系列将被视为稳定。新的次版本可能会引入新的小部件,或更新 GDK 后端中窗口系统协议的实现,但不允许添加其他功能或主题更改。以前,次版本每六个月发布一次,现在将根据需要生成。我们还将继续发布微版本以修复错误和安全问题,至少三年。此后的维护可能会继续,具体取决于可用的志愿者资源数量。具有超过三年长期支持发布周期的操作系统发行版可能需要联系 GTK 团队,以建立反向移植策略。

长期稳定系列中的更新将保持 ABI 稳定。除了这些稳定系列之外,GTK+ 开发将在半稳定的开发系列中继续进行。这些开发版本将在次版本之间包含一些 API 更改,尽管更改将在尽可能的情况下受到限制。这是我们期望 GNOME 应用程序采用的路径,但其他应用程序开发人员如果想要访问最新功能,可以选择此选项,但代价是每个次版本都可能需要一些移植工作。

虽然 GTK+ 团队保留在开发系列中更改 API 的权利,但这并不意味着整个 GTK+ API 在每个版本中都会不断中断;只有特定的,希望很少使用的 API 部分可能会更改,如果更改过于广泛,则很可能会延迟到下一个主要开发周期。我们将确保提前充分沟通这些变化。

新的版本控制方案

新的 GTK+ 版本控制方案是我们到目前为止遵循的“语义版本控制”方案的修改。一旦发布了新的主要稳定版本,开发周期就会开始,我们将

  • 将 pkg-config 文件更新为新的主版本,以允许 GNOME 开发人员在开发期间定位新的 API
  • 将现有的主版本保持在相同的编号
  • 将次版本更新为 90,以指示开发版本

例如,在 3.22.0 版本之后以及新的开发周期开始时,pkg-config 文件将被称为 gtk+-4.0,并且 configure.ac 文件中的版本将设置为 3.90

每六个月将发布一个新的偶数开发版本,例如 x.90x.92x.94,直到 GTK+ 团队确信新的 API 和功能集是稳定的。每个次版本都会增加共享库的 soname,以确保自动化工具可以拾取最终的更改并通知发行商和维护者。一旦我们达到 API 和功能集足够稳定以供更广泛的社区使用,我们将发布一个新的主要版本 (x + 1).0 并声明 API 稳定。

一旦完成此零点版本发布,将创建一个新的稳定分支,并且主分支将升级到下一个 90 版本并开始新的开发周期。90 版本可以与之前的稳定版本并行安装。

gtk-versioning-scheme

3.22 将是 3.x 系列的最后一个次要版本,新的版本控制方案将从 3.90 开始生效。3.22 版本在该方案中是不规则的,因为它是一个长期稳定版本,但不会收到进一步的次要版本,并且没有 .0 版本号。这是一个必要的过渡步骤。

下一步是什么

有关这些计划的更多详细信息,包括针对库开发人员和分发包管理器的具体信息,将在后续的博客文章中发布。GTK+ 开发博客还将继续提供有关 GTK+ 本身技术更改的更新,以便提供有关每个即将发布的主要版本中将出现哪些更改的信息。

我们对这些计划感到兴奋,并希望它们将迎来 GTK+ 的新时代,在此时代中,应用程序作者可以对我们的平台更有信心,同时仍然允许我们在 3.x 系列中看到的快速开发步伐。

本文中提出的计划取代了 2016 年 6 月多伦多 GTK+ 黑客马拉松之后公开的计划。

关于“GTK+ 的版本控制和长期稳定性承诺”的 6 个想法

  1. 引用通告:GTK+ 进展 | 近况

评论已关闭。