CLI开发工具【免费下载链接】cliThe Docker CLI项目地址https://gitcode.com/gh_mirrors/cli5/cli点击查看免费下载导读本文以 Docker CLI 仓库中随附的 OpenTelemetry Go 官方发布指南vendor/go.opentelemetry.io/otel/RELEASING.md为骨架系统梳理go.opentelemetry.io/otel一个完整版本从立项、语义约定升级、Breaking Changes 校验、预发布、打 Tag、GPG 签名、创建 GitHub Release 到 post-release 收尾的全过程。读完本文你将掌握 OpenTelemetry Go 多模块仓库的发布实操命令make prerelease、make add-tags、make semconv-generate等理解versions.yaml中 module-sets 的版本联动机制并了解 Docker CLI 这类下游项目如何消费这些已发布版本。文中所有命令与文件均可在当前仓库中直接定位验证。一、发布前奏创建Version Releaseissue一切发布工作从创建一个名为Version Release的 issue 开始。它充当本次发布的任务看板用于追踪发布流程中的每一项待办。后续章节中的所有步骤升级语义约定、校验、打 Tag、签名、收尾都应以该 issue 的 checklist 为主线推进并在全部完成后关闭它。这一做法与仓库内其他约定一致vendor/go.opentelemetry.io/otel/CHANGELOG.md顶部始终保留## [Unreleased]区块并夹在!-- Released section --与!-- Released section ended --注释之间确保已发布内容不会被后续改动误覆盖——发布任务的可追踪性从 issue 到 changelog 一以贯之。二、Semantic Convention 升级OpenTelemetry Semantic Conventions语义约定会随规范演进发布新版本每次发布都可能带来新的属性、重命名或属性合并。此时需要为semconv包生成对应新版本子包并同步更新整个代码库的引用。2.1 生成新的 semconv 子包使用semconv-generatemake 目标完成生成步骤如下将TAG环境变量设置为要生成的语义约定标签在本仓库根目录执行make semconv-generate。export TAGv1.30.0 # 换成你要生成的发布版本 make semconv-generate # 使用上面导出的 TAG执行后会在semconv目录下生成一个新的子包例如semconv/v1.30.0/。提交 PR 前务必人工检查生成结果是否正确。从 Makefile 源码可以看到该目标的真实执行链它先强制校验TAG是否设置未设置直接报错退出然后通过mkdir -p创建目标目录再以 Docker 方式运行weaver镜像执行registry generate从语义约定仓库按$(TAG)标签拉取model并渲染 Go 模板最后调用semconvkit工具完成收尾-semconv semconv/ -tag $(TAG)。也就是说生成本质上是下载语义约定规范 模板渲染 工具整理的流水线而不是手写代码。2.2 更新 CHANGELOG在CHANGELOG.md中追加新条目指明新增的 semconv 包及其升级路径。官方给出的模板如下- 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/077c1fb166be3ba6b4c3e6e04e3a25a8) for information on how to upgrade from go.opentelemetry.io/otel/semconv/PREVIOUS VERSION. (#PR_NUMBER)提示记得把版本号改成本次实际发布与上一个发布对应的版本。当前仓库的 CHANGELOG.md 中就有现成的范例例如v1.45.0版本条目中同时新增了v1.42.0与v1.43.0两个 semconv 包并各自带上了迁移文档链接与 PR 编号。每个生成的 semconv 子包目录下也确实存在由生成器产出的MIGRATION.md例如 semconv/v1.43.0/MIGRATION.md其内容会明确说明该版本是否为前一版本的 drop-in replacement可直接替换。2.3 更新全代码库的 semconv import新 semconv 模块生成后需要把代码库中所有旧版本 import 升级到新版本// 之前 semconv go.opentelemetry.io/otel/semconv/v1.37.0 go.opentelemetry.io/otel/semconv/v1.37.0/otelconv // 之后 semconv go.opentelemetry.io/otel/semconv/v1.39.0 go.opentelemetry.io/otel/semconv/v1.39.0/otelconv改完后运行make检查编译与测试是否通过。这里的 import 升级之所以是全代码库范围是因为 Go module 采用语义化导入路径semantic import versioning版本号直接体现在 import path 中升级即意味着批量改 import——这一点在 VERSIONING.md 中有明确约定。2.4 处理属性变更Handling attribute changes某些语义约定版本会新增属性或影响当前正在使用的属性。变更可能只是简单重命名也可能是复杂的属性合并与属性值变化。处理原则是代码应迁移到取代旧属性的新属性以贴合最新的语义约定但出于兼容考虑遗留属性仍可依据OTEL_SEMCONV_STABILITY_OPT_IN环境变量继续输出。如果希望参考一次真实的属性迁移是如何跟踪与执行的可以查看 open-telemetry/opentelemetry-go 的 issue #7806该 issue 记录了相关迁移过程与检查清单。2.5 同步更新 contrib 仓库的 linter 约束语义约定升级还会影响配套的 opentelemetry-go-contrib 仓库需要更新其中的.golangci.yml强制要求使用新的 semconv 版本从而保证 contrib 生态与主仓库保持一致。三、Breaking Changes 校验发布前必须确认公开 API 没有发生非预期的破坏性变更。执行make gorelease该目标会运行 gorelease 工具逐一检查所有子模块的公开 API 差异。从 Makefile 可见gorelease会遍历$(OTEL_GO_MOD_DIRS)下的每个go.mod目录逐个cd进入并运行gorelease工具因此校验覆盖整个多模块仓库。gorelease 自身的已知问题可以在 Go 官方 issue 跟踪器golang.org/issues/26420中查看或报告。四、验证对 contrib 仓库的兼容性如果主仓库的变更会影响 contrib 仓库则必须在发布前验证兼容性。具体做法是遵循 contrib 仓库 RELEASING.md 中 Verify OTel changes 一节描述的步骤在主仓库变更之上验证 contrib 的构建与测试。这一步与上一节的 gorelease 校验互为补充gorelease 管API 契约contrib 验证管生态兼容。五、Pre-Release版本决策与预发布分支这是决定哪些模块以什么版本发布的关键一步。5.1 确定 module sets 并更新 versions.yaml首先决定本次要发布哪些 module set模块组并在versions.yaml中更新它们的版本号然后把这笔变更提交到一个新分支。versions.yaml是发布版本事实的唯一来源。当前仓库中定义的 module sets 如下节选自 versions.yamlModule Set当前版本包含的代表性模块stable-v1v1.46.0go.opentelemetry.io/otel、otel/metric、otel/sdk、otel/sdk/metric、otel/trace、OTLP/Stdout/Zipkin exporters、bridge 等experimental-metricsv0.68.0exporters/prometheus、metric/xexperimental-logsv0.22.0log、sdk/log、OTLP log exportersexperimental-schemav0.0.19schema从 VERSIONING.md 可理解这一设计的深层逻辑稳定模块stable共享完全相同的版本号——即使某模块本次没有改动也会为了与其他被改动的稳定模块保持版本一致而跟着递增 minor 或 patch实验性模块以v0版本维护向后不兼容变更通过递增 minor 实现patch 仅用于向后兼容修复semver 有一个例外约定允许在 minor release 中向导出的 API 接口添加新方法相关接口的公开文档中都会包含 Warning: methods may be added to this interface in minor releases 的提示。5.2 更新子模块 go.mod 依赖并执行 prerelease更新versions.yaml后还需更新各子模块的go.mod使其依赖即将在下一步发布的新版本。然后执行 prerelease 目标make prerelease MODSETmodule setmake prerelease在 Makefile 中的实现为prerelease: verify-mods [ ${MODSET} ] || ( echo env var MODSET is not set; exit 1 ) $(MULTIMOD) prerelease -m ${MODSET}它会先运行verify-mods即multimod verify校验 module sets 配置一致性强制要求设置MODSET环境变量否则直接报错退出调用multimod工具执行 prerelease创建一个名为prerelease_module set_new tag的分支承载本次发布的所有版本变更。5.3 验证并合并预发布分支git diff ...prerelease_module set_new tag该 diff 应把所有模块的版本统一改为new tag。确认无误后将其合并进你的预发布分支git merge prerelease_module set_new tag5.4 整理 CHANGELOG确保本次发布的所有相关变更都已收录且用非贡献者也能读懂的语言书写。可直接查看自last tag以来的提交git --no-pager log --prettyoneline last tag..HEAD把所有Unreleased变更移入一个新 section标题格式为[new tag] - date of release新 section 必须放在!-- Released section --注释之下以免日后被覆盖更新文末所有对应的链接。仓库中的verify_released_changelog.sh脚本正是这一保护机制的落地它会 fetch 目标分支的CHANGELOG.md用awk分别抽取新旧文件中!-- Released section --到!-- Released section ended --之间的已发布区块并diff比对一旦发现已发布部分被改动立即报错退出。5.5 推送并提交 PR把预发布分支推送到 upstream并创建 GitHub Pull Request。PR 描述中务必附上从 CHANGELOG 精选的变更内容。六、Tag为合并提交打版本标签PR 被批准并合并后就该给合并提交打 Tag 了。重要警告 1必须使用与 Pre-Release 步骤完全相同的 Tag否则整个仓库会进入损坏状态。只要你在 pre-release 与打 Tag 之间没有改动versions.yaml一般不会出问题。重要警告 2Go module 一旦错误打 Tag目前没有官方的删除/回滚手段见 golang/go#34189。因此推送上游前务必确认版本号正确否则会引发紧急事故且难以绕开历史上 open-telemetry/opentelemetry-go#331 就是教训。打 Tag 命令make add-tags MODSETmodule set COMMITcommit hash其中COMMIT使用 main 分支上合并 PR 的那个 commit hash。只有当当前工作目录的HEAD不是正确提交时才需要显式提供COMMIT否则可以省略。从 Makefile 可见COMMIT的默认值是HEADCOMMIT ? HEAD add-tags: verify-mods [ ${MODSET} ] || ( echo env var MODSET is not set; exit 1 ) $(MULTIMOD) tag -m ${MODSET} -c ${COMMIT}随后把所有 Tag包括各子模块的 Tag推送到 upstream 远程仓库注意是github.com/open-telemetry/opentelemetry-go.git不是你的 fork并且不要遗漏任何子模块git push upstream new tag git push upstream submodules-path/new tag ...七、签名发布产物Sign artifacts为遵循 CNCF 最佳实践发布产物必须签名从 tags 页面下载新发布 Tag 对应的.tar.gz与.zip两个归档两个归档都需要用你的 GPG 密钥签名可先用官方提供的辅助脚本核对归档内容再签名。查看 GPG 密钥 IDgpg --list-secret-keys --keyid-formatlong密钥 ID 是sec rsa4096/或类似字段之后的 16 位字符串。设置环境变量并签名两个产物export VERSIONversion # 例如 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八、创建 GitHub Release最后在 GitHub 上为new tag创建 Release正文需包含本次发布在 Changelog 中的全部发布说明。重要警告GitHub Releases 一旦创建即不可变immutable。必须在创建 Release 时就上传签名产物.tar.gz、.tar.gz.asc、.zip、.zip.asc四个文件因为之后无法再添加或修改。九、Post-Release 收尾9.1 contrib 仓库发布验证通过后务必为使用本次发布的 contrib 仓库制作对应 Release按 contrib 仓库自己的 RELEASING.md 执行。9.2 官网文档更新更新 OpenTelemetry 官网的 Go 语言插桩文档content/en/docs/languages/go目录把文档中引用的所有包版本升级到本次刚发布的版本确保所有代码示例仍然可以编译、内容准确。9.3 关闭 milestone发布完成后把本次发布修复的 issue 与合并的 PR 全部挂到对应 milestone 上便于追踪每个版本的变更范围查找尚未挂 milestone 的已关闭 issue可用 GitHub issue 搜索查询条件组合为is:issue no:milestone is:closed并排除Stale标签、要求关联 PR查找尚未挂 milestone 的已合并 PR用is:pr no:milestone is:merged查询。全部挂完后关闭该 milestone。9.4 关闭Version Releaseissue当Version Releaseissue 中的待办清单全部完成关闭该 issue一次完整发布就此收官。十、源码佐证发布流程在仓库中的落点上述流程并非空谈每个环节都能在当前仓库找到对应实现发布命令的落地实现Makefile 中semconv-generate、prerelease、add-tags、gorelease、verify-mods等目标逐一对应发布流程各步骤其内部依赖multimod、crosslink、semconvkit、gorelease等构建工具版本决策的事实来源versions.yaml 定义了全部 module sets 及其版本联动关系版本策略的制度依据VERSIONING.md 规定了稳定模块同版本号、实验模块 v0 版本、semver 例外条款等规则Changelog 防篡改机制verify_released_changelog.sh 与 CHANGELOG.md 中!-- Released section --注释共同保证已发布区块不可被覆盖生成的 semconv 包实物semconv 目录下的v1.37.0/、v1.43.0/子包及其MIGRATION.md正是semconv-generate流水线的产物样例。10.1 下游视角Docker CLI 如何消费已发布版本作为本仓库Docker CLI随附的第三方依赖OTel 的版本策略直接影响了下游项目的升级方式。在 cli/command/telemetry.go 中Docker CLI 通过语义化导入路径引用固定版本的 semconvsemconv go.opentelemetry.io/otel/semconv/v1.37.0并依赖otel.GetTracerProvider()/otel.GetMeterProvider()获取全局 provider通过resource.New构造资源注入semconv.ServiceInstanceID(uuid.NewString())保证每次 CLI 调用都是独立实例。而 cli/command/telemetry_docker.go 则从 Docker context 元数据或DOCKER_CLI_OTEL_EXPORTER_OTLP_ENDPOINT环境变量读取 OTLP endpoint创建otlptracegrpc/otlpmetricgrpc导出器并把导出超时收紧到 50ms 级别exportTimeout避免遥测拖慢 CLI 退出。这意味着当 OTel 发布新版 semconv 时Docker CLI 这类下游必须按照本文第 2.3 节的方式升级 import 并重新验证——这正是语义化导入版本 严格发布流程的价值所在发布方保证版本契约消费方获得可预期的升级路径。十一、发布流程自查清单为便于执行将全文要点浓缩为一份可直接对照的清单创建Version Releaseissue 并建立待办语义约定升级export TAG... make semconv-generate→ 检查生成的子包 → 更新 CHANGELOG → 全库升级 import →make验证 → 处理属性变更OTEL_SEMCONV_STABILITY_OPT_IN→ 同步 contrib linterBreaking changes 校验make gorelease验证 contrib 兼容性Pre-Release更新versions.yaml提交到新分支 → 更新子模块 go.mod →make prerelease MODSETset→git diff验证 → merge → 整理 CHANGELOG移入[new tag] - date区块→ 推送 PRTagmake add-tags MODSETset COMMIThash→ 推送全部 Tag含子模块务必推送到 upstream签名下载 tar.gz/zip → GPG 生成.asc→ 验证签名Release创建 GitHub Release 并一次性上传四个签名产物Release 不可变Post-Release发布 contrib → 更新官网 Go 文档 → 关闭 milestone → 关闭Version Releaseissue。高频风险点Tag 与 Pre-Release 版本不一致、漏推子模块 Tag、错误版本无法回滚、Release 创建后遗漏签名产物——这四类问题都会造成发布事故务必在每一步双检。赞分享CLI开发工具【免费下载链接】cliThe Docker CLI项目地址https://gitcode.com/gh_mirrors/cli5/cli点击查看免费下载相关推荐OpenTelemetry Go SDK 发布流程全解析从 Semantic Convention 升级到 GPG 签名与 Post-Release 收尾OpenTelemetry Go SDK 发布流程全解析从 Semantic Convention 升级到 GPG 签名与 Post Release 收尾 本云原生集群管理运维IaCOpenTelemetry Go SDK 发布流程实战指南从语义约定升级到 GPG 签名发布OpenTelemetry Go SDK 发布流程实战指南从语义约定升级到 GPG 签名发布 本指南以本仓库中随依赖一并 vendored 的 vendor/文档教程Vibe Coding示例工程OpenTelemetry Go 发布流程全解析从 Semantic Convention 升级到版本打签、制品签名与发布收尾OpenTelemetry Go 发布流程全解析从 Semantic Convention 升级到版本打签、制品签名与发布收尾 本文基于 linuxkit 仓操作系统云原生容器运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
