Skip to content

发布检查清单

此文档描述了打包和发布新的NetBox版本的流程。有三种类型的发布：

  • 主要版本发布（例如，从v2.11到v3.0）
  • 次要版本发布（例如，从v3.2到v3.3）
  • 补丁版本发布（例如，从v3.3.0到v3.3.1）

尽管主要版本发布通常引入了一些对应用程序的非常重大的更改，但它们通常在发布打包的目的上与次要版本增量相同对待。

次要版本发布

处理受限制的依赖项

有时需要将依赖项限制到特定版本，例如，以解决较新版本中的错误或避免我们尚未适应的破坏性更改。 （另一个常见示例是限制上游的Django版本。）例如：

# https://github.com/encode/django-rest-framework/issues/6053
djangorestframework==3.8.1

这些版本约束被添加到base_requirements.txt，以确保在更新requirements.txt中的固定依赖项时不会安装更新的软件包（请参阅下面的更新要求部分）。在每个新的NetBox次要版本发布之前，应该尽可能解决所有这些对依赖包的约束。这可以防止随着时间的推移收集过时的约束。

关闭发布里程碑

在确保与之相关联的问题没有保留的情况下，在GitHub上关闭发布里程碑。

更新发布说明

检查新版本的发布说明链接是否在导航菜单中（在mkdocs.yml中定义），并确保已在docs/index.md中添加了所有主要新功能的摘要。

手动执行新安装

启动文档服务器，并导航到当前版本的安装文档：

mkdocs serve

按照这些说明在临时环境中执行NetBox的新安装。此过程不得自动化：此步骤的目标是捕获文档中的任何错误或遗漏，并确保它针对每个发布保持最新。在继续发布之前，对文档进行任何必要的更改。

合并发布分支

提交拉取请求，将feature分支合并到develop分支，以准备发布。一旦合并完成，继续下面的补丁版本发布部分。

重建演示数据（发布后）

在发布新的次要版本之后，生成与新版本兼容的新演示数据快照。请参阅netbox-demo-data存储库中的说明。

补丁版本发布

通知netbox-docker项目有关的更改

通知netbox-docker的维护者（在#netbox-docker中），任何可能与其构建过程相关的更改，包括：

  • 对upgrade.sh的重大更改
  • 服务依赖项（PostgreSQL、Redis等）的最低版本的提高
  • 对参考安装的任何更改

更新要求

在每次发布之前，将NetBox的每个Python依赖项更新到其最新稳定版本。这些依赖项在requirements.txt中定义，使用pip从base_requirements.txt中更新。要执行此操作，请执行以下步骤：

  1. 升级环境中所有必需包的安装版本（pip install -U -r base_requirements.txt）。
  2. 运行所有测试，并检查UI和API是否按预期运行。
  3. 检查每个要求的发行说明，以查看是否有任何重大的破坏性或值得注意的更改。
  4. 根据需要更新requirements.txt中的软件包版本。

在将依赖项升级到其最新版本会导致问题的情况下，应该在base_requirements.txt中将其限制为当前次要版本，并附带说明性注释，然后在下一个主要NetBox版本发布时重新审查（请参阅上面的处理受限制的依赖项部分）。

重建设备类型定义模式

运行以下命令以更新设备类型定义验证模式：

./manage.py buildschema --write

这将自动更新位于 contrib/generated_schema.json 的模式文件。

更新和编译翻译

登录到 Transifex 下载更新的字符串映射。为每种语言下载资源文件（可移植对象，或 .po 文件），并将它们保存到 netbox/translations/$lang/LC_MESSAGES/django.po，覆盖当前的文件（确保点击 Download for use 链接）。

Transifex下载

一旦所有语言的资源文件都被更新，使用 compilemessages 管理命令来编译机器对象（.mo）文件：

./manage.py compilemessages

更新版本和更改日志

  • 在 settings.py 中更新 VERSION 常量为新的发布版本。
  • 在 .github/ISSUE_TEMPLATES/ 下更新特性请求和错误报告模板中的示例版本号。
  • 在发布说明中用当前日期替换 "FUTURE" 占位符。

将这些更改提交到 develop 分支并推送到上游。

验证 CI 构建状态

确保 develop 分支上的持续集成测试成功完成。如果失败，请采取措施纠正失败，然后再继续发布流程。

提交拉取请求

提交一个拉取请求，标题为 "Release vX.Y.Z"，将 develop 分支合并到 master 分支。将记录的发布说明复制到拉取请求的正文中。

一旦 CI 完成了 PR，就可以合并它。这将在 master 分支上创建一个新的发布。

创建新的发布

在 GitHub 上创建一个新的发布，使用以下参数。

  • 标签： 当前版本（例如v3.3.1）
  • 目标： master
  • 标题： 版本和日期（例如v3.3.1 - 2022-08-25）
  • 描述： 从拉取请求正文复制

一旦创建，发布将可供用户安装。

更新开发版本

在develop分支上，将settings.py中的VERSION更新为下一个版本。例如，如果刚刚发布了v3.3.1，则设置为：

VERSION = 'v3.3.2-dev'

使用"PRVB"（代表_发布后版本提升_）的注释提交此更改，并将提交推送到上游。