操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载导读本文以 OpenTelemetry Go 官方仓库的 RELEASING.md 为骨架完整还原其多模块multi-module发布流程包括 Semantic Convention 代码生成、Breaking Change 校验、Pre-Release 版本号变更、Git Tag 打标与 Release 创建以及发布后的 contrib 仓库、官网文档与 Demo 仓库的联动更新。读完本文你将掌握一套可复用的 Go 多模块仓库版本发布 SOP并能理解Makefile、versions.yaml、CHANGELOG.md等文件在发布链路中的具体角色。说明本文所引用文档位于当前仓库的 vendored 依赖目录pkg/init/vendor/go.opentelemetry.io/otel/下属于 OpenTelemetry Go 官方源码随依赖一并 vendored 进 linuxkit 仓库的产物。文中的路径均以仓库根目录为起点读者可直接点击进入原文继续深入。一、为什么要有一套专门的发布流程多模块仓库的版本困境OpenTelemetry Gogo.opentelemetry.io/otel不是一个单一 Go module而是一个由数十个 module 组成的仓库。在 versions.yaml 中可以看到仓库按module set模块集组织版本线stable-v1主版本线v1.31.0包含核心go.opentelemetry.io/otel、sdk、sdk/metric、trace、metric以及各类 exporterotlpgrpc / otlphttp / stdout / zipkin等稳定模块experimental-metricsv0.53.0包含 prometheus exporter 等实验模块experimental-logsv0.7.0包含log、sdk/log等日志信号模块experimental-schemav0.0.10包含schema模块excluded-modulesinternal/tools这类仅供仓库内部使用的模块不参与发布。这种结构决定了发布动作必须一次性、原子性地作用于整个模块集而不是单个包。Makefile 中几乎所有发布相关 targetprerelease、add-tags、gorelease都依赖$(MULTIMOD)工具go.opentelemetry.io/build-tools/multimod见 Makefile和verify-mods前置校验目的就是保证模块集内所有 module 的版本一致、依赖互相指向新版本。因此整个发布流程被拆成五个阶段Semantic Convention 生成 → Breaking Change 校验 → Pre-Release → Tag → Release → Post-Release每一步都有对应的 make target 和人工校验点。二、Semantic Convention 生成make semconv-generateOpenTelemetry 语义约定Semantic Conventions是各语言 SDK 共享的规范。每当 OpenTelemetry Semantic Conventions 发布新版本semconv包就需要重新生成这是版本升级的前置步骤。2.1 操作步骤原文完整流程export TAGv1.21.0 # 改为你要生成的目标语义约定版本 export OTEL_SEMCONV_REPO/absolute/path/to/opentelemetry/semantic-conventions docker pull otel/semconvgen:latest make semconv-generate # 使用上面导出的 TAG 和 OTEL_SEMCONV_REPO具体三步为将 OpenTelemetry Semantic Conventions 仓库检出checkout到目标 release tag 的本地副本拉取最新otel/semconvgen镜像docker pull otel/semconvgen:latest在本仓库执行make semconv-generate ...。执行成功后会在semconv下生成一个新的子包按版本号命名。提交 Pull Request 前务必人工核对生成结果是否正确。2.2 源码级解读Makefile 中发生了什么在 Makefile 中semconv-generate的实际逻辑是SEMCONVPKG ? semconv/ .PHONY: semconv-generate semconv-generate: $(SEMCONVGEN) $(SEMCONVKIT) [ $(TAG) ] || ( echo TAG unset: missing opentelemetry semantic-conventions tag; exit 1 ) [ $(OTEL_SEMCONV_REPO) ] || ( echo OTEL_SEMCONV_REPO unset: missing path to opentelemetry semantic-conventions repo; exit 1 ) $(SEMCONVGEN) -i $(OTEL_SEMCONV_REPO)/model/. --onlyattribute_group -p conventionTypetrace -f attribute_group.go -t $(SEMCONVPKG)/template.j2 -s $(TAG) $(SEMCONVGEN) -i $(OTEL_SEMCONV_REPO)/model/. --onlymetric -f metric.go -t $(SEMCONVPKG)/metric_template.j2 -s $(TAG) $(SEMCONVKIT) -output $(SEMCONVPKG)/$(TAG) -tag $(TAG)可以提炼出几个关键点两个环境变量缺一不可TAG语义约定版本和OTEL_SEMCONV_REPO语义约定仓库本地路径。Makefile 里用显式[ $(TAG) ] || exit 1做了强校验缺失任一变量会直接终止SEMCONVGEN是构建工具包名为go.opentelemetry.io/build-tools/semconvgen见 Makefile以 Docker 镜像otel/semconvgen:latest提供运行环境生成分两类模板attribute_group模板生成attribute_group.gotrace 类型metric模板生成metric.go输入统一指向OTEL_SEMCONV_REPO/model/.语义约定仓库的 model 目录YAML 模型定义所在SEMCONVKIT负责落盘包名为go.opentelemetry.io/otel/internal/tools/semconvkit把生成结果输出到semconv/TAG/新子目录。在当前 vendored 副本中可以实际看到这一机制的历史产物semconv 下存在v1.20.0/、v1.21.0/、v1.26.0/三个按版本号命名的子包——这正是多次semconv-generate运行留下的累积结果也印证了“每次新版本生成一个新子包”的流程描述。三、Breaking Changes 校验make gorelease语义化版本承诺semver要求公共 API 不能被破坏性修改。OpenTelemetry Go 用gorelease工具做自动校验make gorelease该 target 在 Makefile 中定义为遍历OTEL_GO_MOD_DIRS即除internal/tools外的所有含go.mod的目录对每个 module 依次执行goreleasegorelease工具来源为golang.org/x/exp/cmd/gorelease见 Makefile它通过对比两个版本当前工作区 vs 上一个 tag的公共 API 差异输出破坏性变更报告如果发现非预期的公共 API 变化就需要在发布前修正而不是等到用户升级依赖时才发现兼容性问题。实践建议把make gorelease纳入发布前的强制检查项与 CI 中的 lint、测试、verify-mods同等对待。四、contrib 仓库兼容性验证主仓库opentelemetry-go的 API 变更往往会波及下游的 contrib 仓库opentelemetry-go-contrib即各类 instrumentation 库的集合。RELEASING.md 明确要求如果本次主仓库的变更可能影响 contrib 仓库必须先按 contrib 仓库 RELEASING.md 中 Verify OTel changes 一节描述的步骤验证变更与 contrib 仓库的兼容性。这一步是发布前的一层“影响面审计”避免主仓库发布后立即破坏大量下游 instrumentation 包的编译。五、Pre-Release版本号变更与 Changelog 整理5.1 决定发布哪些模块集并更新 versions.yaml发布的第一步是决策本次要发布哪些 module set。决定后在versions.yaml中更新对应 module set 的version字段例如把stable-v1从v1.31.0改到v1.32.0并把这个改动提交到一个新分支上。紧接着要更新各个子模块的go.mod让它们依赖即将发布的新版本即后续步骤才会真正打出的 tag。5.2 执行make prereleasemake prerelease MODSETmodule set其底层实现在 Makefile.PHONY: prerelease prerelease: verify-mods [ ${MODSET} ] || ( echo env var MODSET is not set; exit 1 ) $(MULTIMOD) prerelease -m ${MODSET}要点MODSET是必填环境变量不设置会直接报错退出MODSET的值即versions.yaml中定义的模块集名字如stable-v1、experimental-logs前置步骤verify-mods调用$(MULTIMOD) verify先校验各模块集配置的一致性执行后multimod会创建一个形如prerelease_module set_new tag的分支该分支包含本次发布的所有版本变更各子模块 go.mod 的依赖版本、versions.yaml 的版本号等。5.3 人工核对变更git diff ...prerelease_module set_new tag核对点所有模块的版本是否都已被改为new tag。确认无误后将该分支合并进你的 pre-release 分支git merge prerelease_module set_new tag5.4 更新 ChangelogRELEASING.md 对 Changelog 的维护有明确规范完整性确保本次发布的所有相关变更都已收录且语言要能让非贡献者看懂。可用以下命令直接核对自上个 tag 以来的提交git --no-pager log --prettyoneline last tag..HEAD归档 Unreleased把所有Unreleased下的变更移入新章节标题遵循[new tag] - date of release格式。在 CHANGELOG.md 中可以看到实际格式例如## [1.31.0/0.53.0/0.7.0/0.0.10] 2024-10-11——多版本线同时发布时用/分隔位置约束新章节必须放在!-- Released section --注释之下避免未来被自动化脚本覆盖该注释在 CHANGELOG.md 中可见更新底部链接同步更新文末的链接索引。5.5 推送并创建 Pull Request将改动推送到上游创建 Pull Request。PR 描述中务必附带从 Changelog 中整理出的发布说明curated changes方便评审者与用户直接了解本次发布内容。六、Tag打标与推送最容易出错的一步6.1 为什么 Tag 必须与 Pre-Release 一致PR 合并后需要对合并 commit 打 tag。RELEASING.md 用两个***IMPORTANT***强调了打标环节的风险Tag 必须与 Pre-Release 步骤中使用的 tag 完全一致。如果 Pre-Release 与打标之间修改了versions.yaml会导致发布状态错乱Go module 的 tag 一旦打错就无法移除Go 模块代理缓存了错误的版本错误版本一旦推送上游会引发连锁的线上事故且难以补救。因此推送前务必反复确认版本号正确。6.2 打标命令对每个要发布的 module set在主干分支合并 PR 的那个 commit 上执行make add-tags MODSETmodule set COMMITcommit hash只有当工作区当前HEAD不是目标 commit 时才需要显式提供COMMIT值Makefile 中COMMIT ? HEAD见 Makefile底层同样是multimod$(MULTIMOD) tag -m ${MODSET} -c ${COMMIT}它会为模块集内每个 module打上对应路径前缀的 tag。6.3 推送 tag含所有子模块git push upstream new tag git push upstream submodules-path/new tag ...注意推送目标是上游 remotegithub.com/open-telemetry/opentelemetry-go.git不是自己的 fork必须逐个推送所有子模块的 tag例如sdk/metric/v1.32.0这类带路径前缀的 tag漏推任何一个都会导致对应 module 无法被go get解析。七、Release创建 GitHub Release打标完成后为新的new tag在 GitHub 上创建 ReleaseRelease body 必须包含本次发布的全部 Changelog 发布说明所有 release notes这一步通常与打标在同一天完成保证 tag 与 Release 一一对应。八、Post-Release发布后的三处联动更新8.1 contrib 仓库主仓库验证通过后需要立即为使用该版本的 contrib 仓库发布新版本让下游 instrumentation 能同步升级到新依赖。8.2 官网 Go 语言文档更新 OpenTelemetry 官网中 Go 语言的 instrumentation 文档content/en/docs/languages/go目录将文档中引用的各包版本号升级为刚发布的最新版本确保文档中所有代码示例仍能编译、内容准确。8.3 Demo 仓库升级 OpenTelemetry Demo 仓库中以下 Go 服务的依赖accountingservicecheckoutserviceproductcatalogservice这三处升级属于“发布收尾”动作目的是让示例与真实 SDK 始终保持同步避免示例代码用过时 API。九、发布流程全景回顾与最佳实践把整个流程串起来一次完整发布的操作序列如下阶段命令 / 操作关键产物验证手段Semconv 生成docker pull otel/semconvgen:latestmake semconv-generatesemconv/TAG/新子包人工核对生成代码API 校验make goreleasegorelease 兼容性报告无破坏性 API 变更影响面审计按 contrib 仓库流程验证兼容性结论contrib 仓库编译/测试Pre-Release改versions.yamlmake prerelease MODSET...prerelease_modset_tag分支git diff核对版本号Changelog归档 Unreleased、更新链接新版本章节git log last tag..HEAD对照Tagmake add-tags MODSET... COMMIT...git push upstream各 module tag核对 tag 与 prerelease 一致ReleaseGitHub 创建 ReleaseRelease notesbody 含完整 ChangelogPost-Releasecontrib 发布、官网文档、Demo 依赖升级同步更新文档可编译、Demo 可运行结合仓库源码可以提炼出几条通用最佳实践适用于任何 Go 多模块仓库用versions.yaml集中管理模块集版本发布决策只改一处让make prerelease这类自动化工具负责机械性的版本替换人工只做git diff审查Tag 是发布流程中唯一“不可逆”的操作Go module 代理会永久缓存错误版本所以打标前必须三查版本号、commit、与 prerelease 一致性Changelog 用!-- Released section --注释做“写保护”避免后续自动化流程覆盖已发布的历史记录发布不是终点contrib 仓库、官网文档、官方 Demo 的联动升级才能保证整个生态步调一致。十、本仓库中的落点vendored 副本的意义这份 RELEASING.md 在当前仓库中位于 pkg/init/vendor/go.opentelemetry.io/otel/RELEASING.md是 linuxkit 的 init 组件依赖 OpenTelemetry Go SDK 时随 vendor 目录一并带入的官方文档。它所在的 otel 目录 完整保留了官方仓库的核心文件——Makefile、versions.yaml、CHANGELOG.md、VERSIONING.md 以及 semconv 下的多个版本子包——这本身就构成了验证本文所述流程的“活标本”你可以在 vendored 副本中直接查看versions.yaml的多版本线结构、比对 CHANGELOG 的[1.31.0/0.53.0/0.7.0/0.0.10]多版本格式、浏览semconv/v1.20.0、semconv/v1.21.0、semconv/v1.26.0等历次生成产物从而把发布流程文档与真实仓库状态一一对应起来。对于负责维护该依赖的开发者而言理解这套发布机制也有助于判断何时需要升级 vendor 中的 OTel 版本以及升级时应该关注哪些兼容性风险。赞分享操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载相关推荐OpenTelemetry Go 多模块发布全流程指南从 Semantic Convention 升级到 GPG 签名 ReleaseOpenTelemetry Go 多模块发布全流程指南从 Semantic Convention 升级到 GPG 签名 Release 导读 OpenTele后端微服务存储认证鉴权opentelemetry-go 版本发布全流程实战Semantic Convention 升级、GPG 签名与多模块 Tag 管理opentelemetry go 版本发布全流程实战Semantic Convention 升级、GPG 签名与多模块 Tag 管理 本文基于 sliver网络安全OpenTelemetry Go 多模块发布流程全解从语义约定生成到 tag、Release 与示例验证OpenTelemetry Go 多模块发布流程全解从语义约定生成到 tag、Release 与示例验证 导读 本文以 OpenTelemetry Go g云原生CLI应用安全上一篇3阶段掌握AI模型微调kohya_ss深度应用指南下一篇Unity游戏微信小游戏终极适配指南5大架构解析与完整性能优化实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考