OpenTelemetry Go SDK 版本发布全流程以 Moby 仓库中 vendored 的 otel 模块为例【免费下载链接】mobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems项目地址: https://gitcode.com/GitHub_Trending/mo/moby导读本文以当前仓库中 vendored 的 vendor/go.opentelemetry.io/otel/RELEASING.md 为核心骨架系统讲解 opentelemetry-gogo.opentelemetry.io/otel从创建Version Release跟踪 issue、升级 Semantic Conventions、校验 breaking changes到 pre-release、打 tag、GPG 签名制品、发布 GitHub Release 以及 post-release 收尾的完整操作链路。读者阅读后可掌握该 Go 观测性 SDK 的模块化版本发布规范并能在 vendor/go.opentelemetry.io/otel 目录内对照 Makefile、versions.yaml、CHANGELOG 与 semconv 子包核实每一步的底层实现与预期产物。一、前置认知这份文档在仓库中的位置与角色该文件位于 Moby 仓库的第三方依赖目录下主文档vendor/go.opentelemetry.io/otel/RELEASING.mdRelease Process 全流程说明配套材料同一 vendored 目录下还完整保存了 vendor/go.opentelemetry.io/otel/Makefilesemconv-generate、gorelease、prerelease、add-tags 等 target 的实现、vendor/go.opentelemetry.io/otel/versions.yamlmodule-set 与版本定义、vendor/go.opentelemetry.io/otel/CHANGELOG.mdKeep a Changelog 风格变更记录以及 vendor/go.opentelemetry.io/otel/semconv 下按版本号排列的多个子包v1.17.0、v1.37.0、v1.43.0。理解这份文档前需要知道两个关键背景本文档描述的是上游 opentelemetry-go 仓库的发布流程。文中的发布操作推分支、打 tag、签名制品、发 Release发生在 opentelemetry-go 自身仓库内而 Moby 仓库将其以 vendor 快照方式引入因此读者可以从本仓库的 vendored 副本核对其中的 Makefile 目标、module 集合与 semconv 布局实际执行发布仍属于上游仓库维护者的职责范围。发布以“module set”为单位而非单一 module。otel-go 采用多 Go module 布局versions.yaml将众多 module 组织为多个 module set详见下文因此每次发布需要批量、一致地推进一批 module 的版本。二、创建Version Release跟踪 issue发布的第一步是在仓库中创建一个Version Releaseissue用于跟踪整个发布流程。该 issue 承担两重职责将发布流程拆分为可勾选的 todo 清单semconv 升级、pre-release、tag、签名、Release、里程碑收尾等在流程结束时Post-Release 阶段勾选并关闭该 issue作为一次发布闭环的存档。从文档结构看issue 与 milestone、CHANGELOG 一起构成“可追溯”的发布证据链每个 PR、每个 issue 都能对应到它被合入/修复的具体版本。三、Semantic Convention 升级前置步骤注原文定义的外部链接OpenTelemetry Semantic Conventions 规范仓库等请读者按需在上游查询下面内容聚焦于本仓库可核对的流程与命令本身。每次上游 [OpenTelemetry Semantic Conventions] 发布新版本都意味着go.opentelemetry.io/otel/semconv包需要重新生成以携带新版本的语义约定。3.1 生成新 semconv 子包生成操作由semconv-generate这个 make target 完成。发布者需要将TAG环境变量设置为要生成的 semantic conventions 版本标签在本仓库otel-go 根目录执行make semconv-generate。文档给出的标准示例export TAGv1.30.0 # Change to the release version you are generating. make semconv-generate # Uses the exported TAG.在本仓库 vendored 副本中可以找到该 target 的真实实现vendor/go.opentelemetry.io/otel/Makefile#L289-L313。实现要点包括TAG未设置时直接报错退出TAG unset: missing opentelemetry semantic-conventions tag强制发布者显式声明版本通过semconvkit工具与 weaver 镜像从指定 tag 拉取语义约定 registry 源码并渲染 Go 代码到semconv/TAG/目录生成完毕后调用$(SEMCONVKIT)对产物做后处理。执行完成后仓库会新增一个semconv/NEW VERSION子包。发布者应先确认生成内容正确再提交 PR 合入。本仓库 vendored 副本中已存在多个历史版本子包可作为“生成后应长什么样”的参照物如 vendor/go.opentelemetry.io/otel/semconv/v1.37.0含 schema.go、exception.go、attribute_group.go 等与 vendor/go.opentelemetry.io/otel/semconv/v1.43.0额外包含 httpconv、otelconv、rpcconv 等转换辅助子包。3.2 更新 CHANGELOG新 semconv 子包加入后需要同步在 vendor/go.opentelemetry.io/otel/CHANGELOG.md 中登记变更文档给出的 changelog 条目模板如下- The go.opentelemetry.io/otel/semconv/NEW VERSION package. The package contains semantic conventions from the NEW VERSION version of the OpenTelemetry Semantic Conventions. See the [migration documentation](https://link.gitcode.com/i/fbf87a2a27f31b837741e91379834886) for information on how to upgrade from go.opentelemetry.io/otel/semconv/PREVIOUS VERSION. (#PR_NUMBER)Tip:将 release 与 prior version 替换为实际的版本号。仓库中的 CHANGELOG 恰好提供了这种条目的实例例如 v1.45.0/0.67.0/0.21.0/0.0.18 一节中“Add thego.opentelemetry.io/otel/semconv/v1.42.0package.”的记录配套的迁移文档也能在本仓库直接看到例如 vendor/go.opentelemetry.io/otel/semconv/v1.43.0/MIGRATION.md说明 v1.43.0 可作 v1.42.0 的 drop-in 替代。3.3 更新全代码库的 semconv 导入路径新 semconv module 生成后需要把整个代码库中所有 semconv 导入批量切换到新版本文档给出了“前后对照”示例// Before semconv go.opentelemetry.io/otel/semconv/v1.37.0 go.opentelemetry.io/otel/semconv/v1.37.0/otelconv // After semconv go.opentelemetry.io/otel/semconv/v1.39.0 go.opentelemetry.io/otel/semconv/v1.39.0/otelconv全部替换完成后运行make检查是否存在编译失败或测试失败。3.4 处理 attribute 变更某些 semconv 版本可能新增 attribute或影响当前正在使用的 attribute——变更可能从简单重命名到更复杂的“合并 attribute / 属性值语义改变”。发布者应将代码迁移到取代旧 attribute 的新 attribute以贴合语义约定但考虑到兼容性旧 attribute 仍可能在OTEL_SEMCONV_STABILITY_OPT_IN环境变量的控制下继续被输出。对于这种迁移应该如何跟踪与执行文档给出了上游 issue#7806作为参考案例可结合该 issue 了解实践中属性迁移的完整过程。3.5 Go contrib linter 更新semconv 版本升级通常还牵动 opentelemetry-go-contrib 仓库需要在其.golangci.yml中强制使用新 semconv 版本确保 contrib 仓库的静态检查与实际依赖保持一致。四、Breaking Changes 校验对外发布公共 API 之前必须确保没有引入“意外”的破坏性变更。执行make gorelease该 target 调用gorelease工具golang.org/x/exp/cmd/gorelease比对公共 API 变化。本仓库的 Makefile 中其实现位于 vendor/go.opentelemetry.io/otel/Makefile#L315-L322它针对所有 Go module 逐一运行 gorelease 输出差异报告。若发现问题可在上游 golang 的 issue#26420处上报或排查。五、验证对 contrib 仓库的兼容性若主仓库的改动会影响 contrib 仓库opentelemetry-go-contrib发布前需要按 contrib 仓库 RELEASING.md 中 “Verify OTel changes” 一节描述的步骤验证主仓库改动与 contrib 仓库的兼容性。该步骤的核心价值在于otel-go 是生态底座主仓库 API 或 semconv 层面的改动会级联影响上层 instrumentation 库提前在 contrib 层面跑通编译与测试能显著降低正式发布后的回归风险。六、Pre-Release发布前准备6.1 决定 module set 并更新 versions.yaml首先决定本次将发布哪些module set并在versions.yaml中更新它们的版本号随后在新分支上提交该变更。module set 是什么本仓库 vendored 的 vendor/go.opentelemetry.io/otel/versions.yaml 提供了直观样例例如stable-v1集合当前版本v1.46.0成员包含go.opentelemetry.io/otel主 module、metric、trace、sdk、sdk/metric、各 OTLP/stdout/zipkin exporter 等另有experimental-metricsv0.68.0、experimental-logsv0.22.0、experimental-schemav0.0.19等集合分别服务于不同稳定性阶段的 APIv1.x 稳定 / v0.x 实验。这正是“一次发布推进一组 module 到同一版本”的机制来源也是 CHANGELOG 标题写作[1.46.0/0.68.0/0.22.0/0.0.19] - date的原因。6.2 运行 prerelease target更新子模块的 go.mod使其依赖下一步即将发生的新版本发布。然后执行make prerelease并指定要发布的 module set。它会创建分支prerelease_module set_new tag承载所有发布相关改动make prerelease MODSETmodule set核对改动确认所有 module 的版本都被改写为新 taggit diff ...prerelease_module set_new tag确认无误后将改动合入发布前分支git merge prerelease_module set_new tag在本仓库 Makefile 中可以查看该 target 的真实执行逻辑vendor/go.opentelemetry.io/otel/Makefile#L328-L331——它依赖multimod工具先执行verify-mods再调用$(MULTIMOD) prerelease -m ${MODSET}MODSET未设置会直接报错。multimod正是依据versions.yaml中 module-set 定义完成批量版本改写的核心工具。6.3 更新 Changelog确保本次发布所有相关变更均已收录且行文能让非贡献者也读懂。可用如下命令直接审查自上个 tag 以来的提交git --no-pager log --prettyoneline last tag..HEAD将Unreleased下的所有变更迁移到新的版本小节标题格式为[new tag] - date of release。确保新小节位于“released section”注释如!-- Released section --之下以在未来的发布中被自动保护、不被覆盖。更新文末所有相关链接。本仓库的 vendor/go.opentelemetry.io/otel/CHANGELOG.md 恰好展示了这套机制的最终形态## [Unreleased]之下紧跟!-- Released section --注释与!-- Dont change this section unless doing release --保护性注释随后是按时间倒序排列的历史版本小节。6.4 提交 PR将改动推送至 upstream 并在 GitHub 创建 Pull RequestPR 描述中必须包含上述整理好的 Changelog 变更内容。七、Tag为合并后的 commit 打标签所有版本变更的 PR 被批准并合并后即可为合并 commit 打 tag。IMPORTANT打 tag 必须与 Pre-Release 步骤使用完全相同的 tag否则会留下 broken state。只要 pre-release 之后不再改动versions.yaml通常不会出错。IMPORTANTGo module 目前无法删除被错误标记的版本上游 golang issue #34189因此必须确保推送到上游的版本号正确无误否则将引发难以规避的连带问题。操作步骤对每个要发布的 module set用主分支上合并 PR 的commit-hash执行make add-tagsmake add-tags MODSETmodule set COMMITcommit hash只有当工作目录当前HEAD不是目标 commit 时才需要显式传COMMIT。将 tag 推送到 upstream remote注意是上游仓库而非 fork并确保所有子模块的 tag 一并推送git push upstream new tag git push upstream submodules-path/new tag ...其底层实现同样位于 vendor/go.opentelemetry.io/otel/Makefile#L333-L337add-tags依赖verify-mods并调用$(MULTIMOD) tag -m ${MODSET} -c ${COMMIT}由 multimod 依据 module-set 定义与指定 commit 批量生成各 module 的版本 tag。由于 vendored 副本中 go.mod 的 module 与子目录层级如 semconv/v1.37.0、semconv/v1.43.0 等独立子 module清晰可查可以直观对应“为何需要逐个子 module 分别推送 tag”。八、签名制品Sign artifacts为遵循 CNCF 最佳实践需要对发布制品做签名从 releases tags 页面下载新 release tag 对应的.tar.gz与.zip归档两者均需使用发布者的 GPG 密钥签名。签名前可用上游提供的脚本核验归档内容。查看 GPG 密钥 IDgpg --list-secret-keys --keyid-formatlong密钥 ID 即sec rsa4096/或类似字段之后的 16 位字符串。设置环境变量并对两个制品签名export VERSIONversion # e.g., v1.32.0 export KEY_IDyour-gpg-key-id gpg --local-user $KEY_ID --armor --detach-sign opentelemetry-go-$VERSION.tar.gz gpg --local-user $KEY_ID --armor --detach-sign opentelemetry-go-$VERSION.zip校验签名gpg --verify opentelemetry-go-$VERSION.tar.gz.asc opentelemetry-go-$VERSION.tar.gz gpg --verify opentelemetry-go-$VERSION.zip.asc opentelemetry-go-$VERSION.zip九、Release创建 GitHub Release在 GitHub 上为新 tag 创建 Release正文应包含本次发布在 Changelog 中的全部 release notes。IMPORTANTGitHub Releases 一经创建即不可变immutable。签名制品.tar.gz、.tar.gz.asc、.zip、.zip.asc必须在创建 Release 时一并上传之后无法补充或修改。十、Post-Release 收尾10.1 Contrib 仓库发布验证通过后需同步为使用本次版本的 contrib 仓库opentelemetry-go-contrib制作对应的 release确保生态版本配套推进。10.2 官网文档更新更新 OpenTelemetry 官网中 Go instrumentation 文档页content/en/docs/languages/go。重点是将文中引用的各包版本号提升为本次发布的最新版本重新验证所有代码示例仍可编译且准确无误。10.3 收尾 milestone每次 release 完成后确保本次发布修复的 issue 与合入的 PR 都被归入对应 milestone以便追踪每个版本包含了哪些变更用 GitHub 搜索找出尚未归入 milestone 的已关闭 issue可加no:milestone is:closed等过滤条件并排除Stale标签、只保留linked:pr的问题找出尚未归入 milestone 的已合并 PR条件类似no:milestone is:merged。全部关联 issue/PR 归入 milestone 后关闭该 milestone。10.4 关闭Version Releaseissue当Version Releaseissue 的 todo 清单全部完成后关闭该 issue一次完整的发布流程就此闭环。总结整个发布流程可以凝练为一条清晰的责任链跟踪创建Version Releaseissue锁定本次发布范围内容准备升级 semconvTAGmake semconv-generate→ 迁移导入 → 更新 CHANGELOG再用make gorelease校验无意外破坏性变更版本改写更新versions.yaml→make prerelease MODSET...批量推进 module 版本 → 合并 PR固化make add-tags MODSET... COMMIT...打 tag 并推送所有子模块 tag可信分发GPG 签名.tar.gz/.zip制品 → 创建不可变的 GitHub Release 并上传签名产物生态收尾发布 contrib 版本、更新官网文档、归拢并关闭 milestone 与跟踪 issue。这套流程中反复出现的versions.yaml、Makefile targetsemconv-generate / prerelease / add-tags / gorelease与 CHANGELOG 约定都可以在当前仓库 vendor/go.opentelemetry.io/otel 目录下找到真实实现与历史样例值得结合阅读从而更准确地把控多 Go module 项目规模化发布时的版本一致性与制品可验证性。【免费下载链接】mobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems项目地址: https://gitcode.com/GitHub_Trending/mo/moby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenTelemetry Go SDK 版本发布全流程：以 Moby 仓库中 vendored 的 otel 模块为例
OpenTelemetry Go SDK 版本发布全流程以 Moby 仓库中 vendored 的 otel 模块为例【免费下载链接】mobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems项目地址: https://gitcode.com/GitHub_Trending/mo/moby导读本文以当前仓库中 vendored 的 vendor/go.opentelemetry.io/otel/RELEASING.md 为核心骨架系统讲解 opentelemetry-gogo.opentelemetry.io/otel从创建Version Release跟踪 issue、升级 Semantic Conventions、校验 breaking changes到 pre-release、打 tag、GPG 签名制品、发布 GitHub Release 以及 post-release 收尾的完整操作链路。读者阅读后可掌握该 Go 观测性 SDK 的模块化版本发布规范并能在 vendor/go.opentelemetry.io/otel 目录内对照 Makefile、versions.yaml、CHANGELOG 与 semconv 子包核实每一步的底层实现与预期产物。一、前置认知这份文档在仓库中的位置与角色该文件位于 Moby 仓库的第三方依赖目录下主文档vendor/go.opentelemetry.io/otel/RELEASING.mdRelease Process 全流程说明配套材料同一 vendored 目录下还完整保存了 vendor/go.opentelemetry.io/otel/Makefilesemconv-generate、gorelease、prerelease、add-tags 等 target 的实现、vendor/go.opentelemetry.io/otel/versions.yamlmodule-set 与版本定义、vendor/go.opentelemetry.io/otel/CHANGELOG.mdKeep a Changelog 风格变更记录以及 vendor/go.opentelemetry.io/otel/semconv 下按版本号排列的多个子包v1.17.0、v1.37.0、v1.43.0。理解这份文档前需要知道两个关键背景本文档描述的是上游 opentelemetry-go 仓库的发布流程。文中的发布操作推分支、打 tag、签名制品、发 Release发生在 opentelemetry-go 自身仓库内而 Moby 仓库将其以 vendor 快照方式引入因此读者可以从本仓库的 vendored 副本核对其中的 Makefile 目标、module 集合与 semconv 布局实际执行发布仍属于上游仓库维护者的职责范围。发布以“module set”为单位而非单一 module。otel-go 采用多 Go module 布局versions.yaml将众多 module 组织为多个 module set详见下文因此每次发布需要批量、一致地推进一批 module 的版本。二、创建Version Release跟踪 issue发布的第一步是在仓库中创建一个Version Releaseissue用于跟踪整个发布流程。该 issue 承担两重职责将发布流程拆分为可勾选的 todo 清单semconv 升级、pre-release、tag、签名、Release、里程碑收尾等在流程结束时Post-Release 阶段勾选并关闭该 issue作为一次发布闭环的存档。从文档结构看issue 与 milestone、CHANGELOG 一起构成“可追溯”的发布证据链每个 PR、每个 issue 都能对应到它被合入/修复的具体版本。三、Semantic Convention 升级前置步骤注原文定义的外部链接OpenTelemetry Semantic Conventions 规范仓库等请读者按需在上游查询下面内容聚焦于本仓库可核对的流程与命令本身。每次上游 [OpenTelemetry Semantic Conventions] 发布新版本都意味着go.opentelemetry.io/otel/semconv包需要重新生成以携带新版本的语义约定。3.1 生成新 semconv 子包生成操作由semconv-generate这个 make target 完成。发布者需要将TAG环境变量设置为要生成的 semantic conventions 版本标签在本仓库otel-go 根目录执行make semconv-generate。文档给出的标准示例export TAGv1.30.0 # Change to the release version you are generating. make semconv-generate # Uses the exported TAG.在本仓库 vendored 副本中可以找到该 target 的真实实现vendor/go.opentelemetry.io/otel/Makefile#L289-L313。实现要点包括TAG未设置时直接报错退出TAG unset: missing opentelemetry semantic-conventions tag强制发布者显式声明版本通过semconvkit工具与 weaver 镜像从指定 tag 拉取语义约定 registry 源码并渲染 Go 代码到semconv/TAG/目录生成完毕后调用$(SEMCONVKIT)对产物做后处理。执行完成后仓库会新增一个semconv/NEW VERSION子包。发布者应先确认生成内容正确再提交 PR 合入。本仓库 vendored 副本中已存在多个历史版本子包可作为“生成后应长什么样”的参照物如 vendor/go.opentelemetry.io/otel/semconv/v1.37.0含 schema.go、exception.go、attribute_group.go 等与 vendor/go.opentelemetry.io/otel/semconv/v1.43.0额外包含 httpconv、otelconv、rpcconv 等转换辅助子包。3.2 更新 CHANGELOG新 semconv 子包加入后需要同步在 vendor/go.opentelemetry.io/otel/CHANGELOG.md 中登记变更文档给出的 changelog 条目模板如下- The go.opentelemetry.io/otel/semconv/NEW VERSION package. The package contains semantic conventions from the NEW VERSION version of the OpenTelemetry Semantic Conventions. See the [migration documentation](https://link.gitcode.com/i/fbf87a2a27f31b837741e91379834886) for information on how to upgrade from go.opentelemetry.io/otel/semconv/PREVIOUS VERSION. (#PR_NUMBER)Tip:将 release 与 prior version 替换为实际的版本号。仓库中的 CHANGELOG 恰好提供了这种条目的实例例如 v1.45.0/0.67.0/0.21.0/0.0.18 一节中“Add thego.opentelemetry.io/otel/semconv/v1.42.0package.”的记录配套的迁移文档也能在本仓库直接看到例如 vendor/go.opentelemetry.io/otel/semconv/v1.43.0/MIGRATION.md说明 v1.43.0 可作 v1.42.0 的 drop-in 替代。3.3 更新全代码库的 semconv 导入路径新 semconv module 生成后需要把整个代码库中所有 semconv 导入批量切换到新版本文档给出了“前后对照”示例// Before semconv go.opentelemetry.io/otel/semconv/v1.37.0 go.opentelemetry.io/otel/semconv/v1.37.0/otelconv // After semconv go.opentelemetry.io/otel/semconv/v1.39.0 go.opentelemetry.io/otel/semconv/v1.39.0/otelconv全部替换完成后运行make检查是否存在编译失败或测试失败。3.4 处理 attribute 变更某些 semconv 版本可能新增 attribute或影响当前正在使用的 attribute——变更可能从简单重命名到更复杂的“合并 attribute / 属性值语义改变”。发布者应将代码迁移到取代旧 attribute 的新 attribute以贴合语义约定但考虑到兼容性旧 attribute 仍可能在OTEL_SEMCONV_STABILITY_OPT_IN环境变量的控制下继续被输出。对于这种迁移应该如何跟踪与执行文档给出了上游 issue#7806作为参考案例可结合该 issue 了解实践中属性迁移的完整过程。3.5 Go contrib linter 更新semconv 版本升级通常还牵动 opentelemetry-go-contrib 仓库需要在其.golangci.yml中强制使用新 semconv 版本确保 contrib 仓库的静态检查与实际依赖保持一致。四、Breaking Changes 校验对外发布公共 API 之前必须确保没有引入“意外”的破坏性变更。执行make gorelease该 target 调用gorelease工具golang.org/x/exp/cmd/gorelease比对公共 API 变化。本仓库的 Makefile 中其实现位于 vendor/go.opentelemetry.io/otel/Makefile#L315-L322它针对所有 Go module 逐一运行 gorelease 输出差异报告。若发现问题可在上游 golang 的 issue#26420处上报或排查。五、验证对 contrib 仓库的兼容性若主仓库的改动会影响 contrib 仓库opentelemetry-go-contrib发布前需要按 contrib 仓库 RELEASING.md 中 “Verify OTel changes” 一节描述的步骤验证主仓库改动与 contrib 仓库的兼容性。该步骤的核心价值在于otel-go 是生态底座主仓库 API 或 semconv 层面的改动会级联影响上层 instrumentation 库提前在 contrib 层面跑通编译与测试能显著降低正式发布后的回归风险。六、Pre-Release发布前准备6.1 决定 module set 并更新 versions.yaml首先决定本次将发布哪些module set并在versions.yaml中更新它们的版本号随后在新分支上提交该变更。module set 是什么本仓库 vendored 的 vendor/go.opentelemetry.io/otel/versions.yaml 提供了直观样例例如stable-v1集合当前版本v1.46.0成员包含go.opentelemetry.io/otel主 module、metric、trace、sdk、sdk/metric、各 OTLP/stdout/zipkin exporter 等另有experimental-metricsv0.68.0、experimental-logsv0.22.0、experimental-schemav0.0.19等集合分别服务于不同稳定性阶段的 APIv1.x 稳定 / v0.x 实验。这正是“一次发布推进一组 module 到同一版本”的机制来源也是 CHANGELOG 标题写作[1.46.0/0.68.0/0.22.0/0.0.19] - date的原因。6.2 运行 prerelease target更新子模块的 go.mod使其依赖下一步即将发生的新版本发布。然后执行make prerelease并指定要发布的 module set。它会创建分支prerelease_module set_new tag承载所有发布相关改动make prerelease MODSETmodule set核对改动确认所有 module 的版本都被改写为新 taggit diff ...prerelease_module set_new tag确认无误后将改动合入发布前分支git merge prerelease_module set_new tag在本仓库 Makefile 中可以查看该 target 的真实执行逻辑vendor/go.opentelemetry.io/otel/Makefile#L328-L331——它依赖multimod工具先执行verify-mods再调用$(MULTIMOD) prerelease -m ${MODSET}MODSET未设置会直接报错。multimod正是依据versions.yaml中 module-set 定义完成批量版本改写的核心工具。6.3 更新 Changelog确保本次发布所有相关变更均已收录且行文能让非贡献者也读懂。可用如下命令直接审查自上个 tag 以来的提交git --no-pager log --prettyoneline last tag..HEAD将Unreleased下的所有变更迁移到新的版本小节标题格式为[new tag] - date of release。确保新小节位于“released section”注释如!-- Released section --之下以在未来的发布中被自动保护、不被覆盖。更新文末所有相关链接。本仓库的 vendor/go.opentelemetry.io/otel/CHANGELOG.md 恰好展示了这套机制的最终形态## [Unreleased]之下紧跟!-- Released section --注释与!-- Dont change this section unless doing release --保护性注释随后是按时间倒序排列的历史版本小节。6.4 提交 PR将改动推送至 upstream 并在 GitHub 创建 Pull RequestPR 描述中必须包含上述整理好的 Changelog 变更内容。七、Tag为合并后的 commit 打标签所有版本变更的 PR 被批准并合并后即可为合并 commit 打 tag。IMPORTANT打 tag 必须与 Pre-Release 步骤使用完全相同的 tag否则会留下 broken state。只要 pre-release 之后不再改动versions.yaml通常不会出错。IMPORTANTGo module 目前无法删除被错误标记的版本上游 golang issue #34189因此必须确保推送到上游的版本号正确无误否则将引发难以规避的连带问题。操作步骤对每个要发布的 module set用主分支上合并 PR 的commit-hash执行make add-tagsmake add-tags MODSETmodule set COMMITcommit hash只有当工作目录当前HEAD不是目标 commit 时才需要显式传COMMIT。将 tag 推送到 upstream remote注意是上游仓库而非 fork并确保所有子模块的 tag 一并推送git push upstream new tag git push upstream submodules-path/new tag ...其底层实现同样位于 vendor/go.opentelemetry.io/otel/Makefile#L333-L337add-tags依赖verify-mods并调用$(MULTIMOD) tag -m ${MODSET} -c ${COMMIT}由 multimod 依据 module-set 定义与指定 commit 批量生成各 module 的版本 tag。由于 vendored 副本中 go.mod 的 module 与子目录层级如 semconv/v1.37.0、semconv/v1.43.0 等独立子 module清晰可查可以直观对应“为何需要逐个子 module 分别推送 tag”。八、签名制品Sign artifacts为遵循 CNCF 最佳实践需要对发布制品做签名从 releases tags 页面下载新 release tag 对应的.tar.gz与.zip归档两者均需使用发布者的 GPG 密钥签名。签名前可用上游提供的脚本核验归档内容。查看 GPG 密钥 IDgpg --list-secret-keys --keyid-formatlong密钥 ID 即sec rsa4096/或类似字段之后的 16 位字符串。设置环境变量并对两个制品签名export VERSIONversion # e.g., v1.32.0 export KEY_IDyour-gpg-key-id gpg --local-user $KEY_ID --armor --detach-sign opentelemetry-go-$VERSION.tar.gz gpg --local-user $KEY_ID --armor --detach-sign opentelemetry-go-$VERSION.zip校验签名gpg --verify opentelemetry-go-$VERSION.tar.gz.asc opentelemetry-go-$VERSION.tar.gz gpg --verify opentelemetry-go-$VERSION.zip.asc opentelemetry-go-$VERSION.zip九、Release创建 GitHub Release在 GitHub 上为新 tag 创建 Release正文应包含本次发布在 Changelog 中的全部 release notes。IMPORTANTGitHub Releases 一经创建即不可变immutable。签名制品.tar.gz、.tar.gz.asc、.zip、.zip.asc必须在创建 Release 时一并上传之后无法补充或修改。十、Post-Release 收尾10.1 Contrib 仓库发布验证通过后需同步为使用本次版本的 contrib 仓库opentelemetry-go-contrib制作对应的 release确保生态版本配套推进。10.2 官网文档更新更新 OpenTelemetry 官网中 Go instrumentation 文档页content/en/docs/languages/go。重点是将文中引用的各包版本号提升为本次发布的最新版本重新验证所有代码示例仍可编译且准确无误。10.3 收尾 milestone每次 release 完成后确保本次发布修复的 issue 与合入的 PR 都被归入对应 milestone以便追踪每个版本包含了哪些变更用 GitHub 搜索找出尚未归入 milestone 的已关闭 issue可加no:milestone is:closed等过滤条件并排除Stale标签、只保留linked:pr的问题找出尚未归入 milestone 的已合并 PR条件类似no:milestone is:merged。全部关联 issue/PR 归入 milestone 后关闭该 milestone。10.4 关闭Version Releaseissue当Version Releaseissue 的 todo 清单全部完成后关闭该 issue一次完整的发布流程就此闭环。总结整个发布流程可以凝练为一条清晰的责任链跟踪创建Version Releaseissue锁定本次发布范围内容准备升级 semconvTAGmake semconv-generate→ 迁移导入 → 更新 CHANGELOG再用make gorelease校验无意外破坏性变更版本改写更新versions.yaml→make prerelease MODSET...批量推进 module 版本 → 合并 PR固化make add-tags MODSET... COMMIT...打 tag 并推送所有子模块 tag可信分发GPG 签名.tar.gz/.zip制品 → 创建不可变的 GitHub Release 并上传签名产物生态收尾发布 contrib 版本、更新官网文档、归拢并关闭 milestone 与跟踪 issue。这套流程中反复出现的versions.yaml、Makefile targetsemconv-generate / prerelease / add-tags / gorelease与 CHANGELOG 约定都可以在当前仓库 vendor/go.opentelemetry.io/otel 目录下找到真实实现与历史样例值得结合阅读从而更准确地把控多 Go module 项目规模化发布时的版本一致性与制品可验证性。【免费下载链接】mobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems项目地址: https://gitcode.com/GitHub_Trending/mo/moby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考