发布产品生命周期结束日期和支持时间线的建议

如果您维护一个具有支持生命周期和生命周期结束概念的产品，以下是我们关于如何最好地为用户记录这些信息的建议。每条建议都包含一些示例（有时是真实的），以帮助解释我们的理由。

清单

这是一份包含我们所有建议的精美清单。这些是我们的建议 - 如果有不适合您的情况，请随意忽略。每个项目都链接到下面文档中的相关部分。

发布

对于较大的项目，您通常会将这些信息分散到多个页面上。我们的建议是，在这种情况下，将这些文档保持良好的链接并托管在一起。例如，不要将您的版本控制策略保留在 wiki 中，而将 EoL 策略保留在您的网站上。

如果可行，我们建议您将自己限制在一个具有适当部分的文档中。

此类文档最好发布在您的网站或 wiki 上。您也可以将其包含在您的存储库中（例如 RELEASE.md 或 EOL.md），但最好的托管位置是您的网站。它提供了一个稳定的 URL，可供您的用户引用。

确保该 URL 在您的发布说明和其他地方清晰链接。让用户易于发现。

不要将其发布到您网站的版本化部分。您的支持策略可能会随着时间而改变，但链接不应改变。

错误示例：https://example.com/docs/v3.4/eol
正确示例：https://example.com/docs/eol
正确示例：https://example.com/release-policy

错误示例 - Ubuntu

Ubuntu 将此信息分散在（未维护的）Ubuntu Wiki 和网站上

确保此信息托管在您的最终用户文档旁边，而不是您的开发人员或团队文档。

错误示例 - Python

Python 在面向 Python 开发人员的网站上维护 EoL 状态：https://devguide.pythonlang.cn/versions/

错误示例 - Ansible

Ansible 的“发布和维护”文档带有版本号，因此有多个副本

这会导致混乱，因为 2.9 分支上的用户可能会错过最新版本中反映的重要信息。

正确示例 - Angular

Angular 项目有一个记录所有信息的单个 URL：https://angular.dev/reference/releases。

记录您的支持生命周期

您的支持生命周期是关于每个产品将获得多长时间支持的指南。如果您有 LTS（长期支持）版本，请阐明这对这些版本有何不同。

错误示例：https://ubuntu.com/about/release-cycle（未解释 LTS 版本支持多长时间）。

发布节奏

并非每个项目都有稳定的发布节奏，但如果您有（即使是粗略的），也请记录下来。如果您的发布节奏是可预测的并且与您的支持生命周期保持一致，那就更好了。

正确示例 - Alpine Linux

Alpine Linux 同时有多个发布分支可用。每年 5 月和 11 月，我们会从 edge 分支创建一个发布分支。主存储库通常支持 2 年，社区存储库支持到下一个稳定版本发布。

来源：https://alpinelinux.cn/releases/

解释支持的内容

每个项目对“支持”的定义都有不同的级别。记录“支持”对您的项目意味着什么非常重要。如果存在不同的层级（例如活动/安全/扩展），请清晰地记录它们。

错误示例

LTS 之外的扩展支持以商业方式提供给客户。

正确示例

LTS 之外的扩展支持以商业方式提供给客户。它仅包括 base 存储库中软件包的关键安全修复。
支付“高级支持”的客户可以获得额外的支持团队访问权限以及保证的服务水平协议 (SLA)。

一个很好的例子是 https://ubuntu.com/security/esm：它清楚地解释了 ESM 对 Ubuntu 最终用户意味着什么。

版本控制策略

记录您的版本控制策略。即使该策略是自制的并且在主要版本之间有所不同，明确记录的策略也胜过没有策略。

正确示例

我们遵循语义化版本控制 (Semantic Versioning)，并将重大更改限制在主要版本升级中。
该项目从 v12 开始遵循 SemVer。以前的版本可能在次要版本升级中包含重大更改。

发布说明

发布说明对于进行升级的最终用户至关重要。如果某些升级路径不受支持（例如同时进行 2 次主要升级），请记录相同的信息。在发布说明中突出显示重大更改。

如果您有迁移指南，请确保在所有发布说明中都链接了它。

列出版本

以表格形式列出您的版本，其中包含每个版本周期的所有相关信息。这包括

指向变更日志（和/或发布说明）的链接。请参阅 keepachangelog.com 了解如何开始使用。
该周期中的最新版本是什么。这有助于用户验证他们运行的是否是受支持的版本。
此版本的重要日期是什么 - EoL/发布/GA/LTS 等。为所有不同的支持级别执行此操作。
下载 URL（如果需要）。
迁移指南（如果可用）。

最好将旧的/不受支持的版本列在其他地方（/historical-releases）。如果您认为它们对用户很重要，请在表格中将其标记为不受支持。

正确示例：https://node.org.cn/en/about/releases/
正确示例：https://php.ac.cn/supported-versions.php
错误示例：https://pythonlang.cn/downloads/（将不受支持的版本与受支持的版本列在一起）

日期

始终使用绝对日期

很多时候，您的支持/EoL 策略是相对的。常见示例

上一个主要版本在新主要版本发布后 90 天变得不受支持。
对以前版本的错误修复将持续到最新版本发布第一个点版本。

但是，您的最终用户不应该需要自己计算。确保您的所有版本始终具有明确的日期（我建议使用 YYYY-MM-DD），无论这些日期是如何确定的。您做一次计算将为您的用户节省更多时间。

错误示例 - 没有明确日期

K8s 版本	AKS GA	生命周期结束
1.22	2021 年 11 月	1.25 GA
1.23	2022 年 2 月	1.26 GA

（来源：Azure Kubernetes 发布日历）

错误示例 - 只有备注

有些项目通常会放置备注而不是记录绝对日期

版本	发布日期
2.1	2021 年 3 月 3 日
2.0	2020 年 3 月 1 日

发布版本从发布日期起支持 2 年。

正确示例

与上面相同，但我们进行了计算

版本	发布日期	EoL 日期
2.1	2021 年 3 月 3 日	2023 年 3 月 3 日
2.0	2020 年 3 月 1 日	2022 年 3 月 1 日

正确示例

Kubernetes 版本	上游发布	Amazon EKS 发布	Amazon EKS 停止支持
1.20	2020 年 12 月 8 日	2021 年 5 月 18 日	2022 年 7 月
1.21	2021 年 4 月 8 日	2021 年 7 月 19 日	2022 年 9 月

来源：Amazon EKS 发布日历。

提供完整日期

始终记录完整日期，而不仅仅是提供月份和年份。用户不应该猜测 EoL 是在 12 月 1 日还是 31 日。

错误示例：请参阅上面的 AKS 和 EKS 示例。
正确示例：https://node.org.cn/en/about/releases/

提供发布计划图表

这是可选的，但清晰的发布周期图形表示总是很好。如果您确实提供了这样的图表，这里有一些建议

对不同的支持级别使用不同的颜色。
使用年份边界清楚地标记您的轴。
有一条直线标记当前日期。
如果可以使其具有交互性，请在悬停时提供开始和结束日期。
确保这些图像保持更新 - 它们很容易过时。过时的图表比没有图表更糟糕。
确保图像中的所有数据也以文本形式（在表格中）反映出来，以方便访问。
通过选择截止日期来限制图像比例。
正确示例：https://php.ac.cn/supported-versions.php
正确示例：https://jefftriplett.com/django-release-cycle/
正确示例：https://hugovk.github.io/drupal-release-cycle/
错误示例：https://docs.nvda.net.cn/datacenter/tesla/drivers/graphics/driver-branches-overview.png（神秘）
错误示例：https://ubuntu.com/about/release-cycle（未提供桌面用户的可访问表格）

欢迎在 GitHub 上对本文档提出反馈。