XcodeGen 发布流程全解析从 CHANGELOG 维护到 GitHub Release 的完整实战指南【免费下载链接】XcodeGenA Swift command line tool for generating your Xcode project项目地址: https://gitcode.com/GitHub_Trending/xc/XcodeGenXcodeGen 是一个用 Swift 编写的命令行工具用于根据一份 YAML/JSON 规格文件spec自动生成 Xcode 工程。本指南聚焦于 RELEASE.md 中记录的官方发布流程围绕如何将一个新版本从代码变更正式交付给全世界的开发者这一核心主题展开。读完本文你将掌握 XcodeGen 的版本号管理机制、make release与make archive的底层执行逻辑、可分发产物xcodegen.zip与xcodegen.artifactbundle.zip的生成原理以及如何在 GitHub 上创建正式的 Release。发布流程总览RELEASE.md 将整个发布过程浓缩为 6 个步骤这 6 步构成了 XcodeGen 每次版本交付的标准操作流程确保CHANGELOG.md内容是最新的包含自上次发布以来所有已合并 PR 的记录并在顶部加入新版本号更新Makefile顶部的版本号运行make release运行make archive将 commit 与 tag 推送到 GitHub在 GitHub 上基于该 tag 创建 Release附加xcodegen.zip和xcodegen.artifactbundle.zip两个产物可以看出发布的核心产物是两种格式的压缩包一个普通 zip供用户手动下载安装一个 Artifact Bundle供 Swift Package Manager 作为命令行插件分发。下面逐一深入每个环节。第一步维护 CHANGELOG.md发布的第一步是保证 CHANGELOG.md 与代码状态完全同步。这是对外沟通版本内容的唯一权威来源也是后续在 GitHub 上撰写 Release notes 时的素材。补充合并的 PR文档明确要求自上次发布以来所有已合并的 PR 都必须被添加到 CHANGELOG并附上 PR 链接和作者。检查依据是执行git log last-tag..HEAD该命令列出从上一个发布 tag 到当前 HEAD 之间的所有提交。从仓库的 CHANGELOG 现状可以看到其规范的条目格式例如- Added support for Swift package traits on remote and local package references, so generated projects preserve the configured trait selections #1629 philprime即每个条目包含变更类型描述 功能细节 PR 编号#1629 贡献者 GitHub 用户名philprime。CHANGELOG 内部按Added/Changed/Fixed/Internal四个类别组织新条目应归入对应分类。添加新版本号CHANGELOG 的顶部结构如下# Change Log ## Next Version ### Added ...发布时需要将当前## Next Version下的内容整理为新版本号小节例如## 2.46.0并在顶部重新开一个空的## Next Version作为下一个开发周期的入口。这样既留住了历史也为未来发布预留了位置。第二步更新 Makefile 顶部的版本号Makefile是发布流程的中枢其顶部的VERSION变量是版本号的唯一手工维护入口。以当前仓库为例MakefileTOOL_NAME XcodeGen export EXECUTABLE_NAME xcodegen VERSION 2.46.0发布新版本时直接把VERSION改成目标版本号如2.47.0。从源码结构看这个版本号会被make release自动注入到另外两个文件中详见下一步因此不要手工去改其他地方的版本号否则会在make release时被覆盖或造成不一致。第三步运行 make releasemake release是版本号落地的关键一步。查看 Makefile 中release目标的定义release: sed -i s|\(let version Version(\)\(.*\)\()\)|\1$(VERSION)\3| Sources/XcodeGen/main.swift sed -i s|\(.package(url: https://github.com/yonaskolb/XcodeGen.git, from: \)\(.*\)\()\)|\1$(VERSION)\3| README.md git add . git commit -m Update to $(VERSION) #git tag $(VERSION)它依次完成三件事1. 同步 main.swift 中的运行时版本号第一行sed作用于 Sources/XcodeGen/main.swift将其中let version Version(2.46.0)的版本号替换为$(VERSION)的值let version Version(2.46.0) let cli XcodeGenCLI(version: version) cli.execute()这个version会被注入 Sources/XcodeGenCLI/XcodeGenCLI.swift 中的CLI对象最终通过xcodegen --version输出给用户。也就是说用户看到的版本号正是从这里来的保持它与 Makefile 同步至关重要。2. 同步 README 中的依赖版本声明第二行sed作用于 README.md更新其中通过 Swift Package Manager 引入 XcodeGen 时使用的from:版本约束确保文档中的安装方式始终指向最新发布版本。3. 生成提交并可选打 tag最后执行git add .和git commit -m Update to $(VERSION)将版本号变更与 CHANGELOG 更新一起打包成一次提交。注意git tag $(VERSION)这行是被注释掉的——RELEASE.md 中虽然写了推送 commit 和 tag 到 GitHub但 tag 的创建时机可以由维护者自行决定通常是在确认 archive 产物无误后再打 tag 并推送避免 tag 指向不完整的提交。第四步运行 make archive 生成分发产物make archive负责生成最终对外分发的两个压缩包。查看 Makefile 中archive目标的定义archive: build ./scripts/archive.sh $(EXECUTABLE_PATH) swift package plugin --allow-writing-to-package-directory generate-artifact-bundle \ --package-version $(VERSION) \ --executable-name $(EXECUTABLE_NAME) \ --build-config release \ --include-resource-path LICENSE它依赖build目标即先用 SwiftPM 以 release 配置编译出可执行文件。注意 Makefile 中的编译参数SWIFT_BUILD_FLAGS --disable-sandbox -c release --arch arm64 --arch x86_64 BUILD_PATH $(shell swift build $(SWIFT_BUILD_FLAGS) --show-bin-path) EXECUTABLE_PATH $(BUILD_PATH)/$(EXECUTABLE_NAME)采用--arch arm64 --arch x86_64双架构编译构建出的二进制可同时运行于 Apple Silicon 与 Intel Mac这正是产物能够通用分发的前提。普通 zip 的打包逻辑make archive第一步调用 scripts/archive.sh其打包结构如下复制编译产物到bin/目录复制 SettingPresets 整个目录到share/xcodegen/SettingPresets这些预设文件是生成工程时依赖的构建设置模板必须随二进制一起分发复制 scripts/install.sh 与 LICENSE 到压缩包内打包成xcodegen.zip并输出 SHA-256 校验值供用户在下载后核验文件完整性。install.sh是解压后的一键安装脚本scripts/install.sh它会将bin与share目录复制到/usr/local下最终形成/usr/local/bin/xcodegen/usr/local/share/xcodegen/SettingPresetsArtifact Bundle 的生成原理第二步通过 SwiftPM 插件generate-artifact-bundle生成xcodegen.artifactbundle.zip。Artifact Bundle 是 SwiftPM 官方的可执行产物分发格式适用于将命令行工具作为 Swift Package 插件依赖引入的场景例如在 Xcode Cloud 或 CI 中通过插件方式调用 xcodegen。该能力由 Package.swift 中声明的外部依赖ArtifactBundleGen版本0.0.8提供.package(url: https://github.com/freddi-kit/ArtifactBundleGen, exact: 0.0.8)命令参数中--package-version $(VERSION)声明 bundle 对应的版本号--executable-name xcodegen指定可执行文件名称--build-config release使用 release 构建--include-resource-path LICENSE将许可证文件包含进 bundle满足开源分发要求。值得一提的是Makefile 中还有一个publish目标它依赖archive并在完成后打印published $(VERSION)作为确认信息可视为整个归档流程的收尾入口。第五步推送 commit 与 tagmake release生成本地提交后需要将其推送到远程仓库。建议顺序为git push origin branch git push origin tag先推送包含版本号更新与 CHANGELOG 的 commit再推送对应的版本 tag。tag 名称应与VERSION保持一致例如2.46.0这样 GitHub 才能把 Release 与正确的代码状态关联起来。第六步在 GitHub 上创建 Release最后一步是在 GitHub 上基于刚才推送的 tag 创建 Release标题使用版本号如2.46.0内容直接采用 CHANGELOG 中对应版本小节的条目保持与仓库历史一致附件上传xcodegen.zip和xcodegen.artifactbundle.zip两个文件。这两个附件正是用户侧两种安装方式的来源前者用于下载解压后执行install.sh的本地安装后者用于通过 SwiftPM Artifact Bundle 机制集成。Release 发布后README 中对应的 SPMfrom:版本约束与xcodegen --version输出即与实际交付的代码完全对齐。发布流程的自动化保障与验证从仓库结构看XcodeGen 的发布流程与持续集成测试是配套的发布前建议确认以下内容Fixture 一致性scripts/diff-fixtures.sh 会检查Tests/Fixtures目录下生成的 fixture 工程是否与预期一致若git status检测到变更则报错退出。该脚本由 CI 在测试阶段执行确保生成器的输出具有确定性避免发布版本产生意外的工程差异。单元测试Tests 目录下的多个测试 Target如XcodeGenKitTests、FixtureTests、ProjectSpecTests等见 Package.swift覆盖了生成器、规格解析、fixture 等关键逻辑可通过swift test在本地运行验证。变更记录发布 commit 应当仅包含版本号同步、CHANGELOG 更新等与发布相关的改动避免混入功能变更。相关文件速查发布流程涉及的关键文件均可在仓库根目录下直接查看文件作用RELEASE.md官方发布流程文档本文主题Makefile版本号入口与release/archive/publish目标定义CHANGELOG.md版本变更记录Release notes 的素材来源Sources/XcodeGen/main.swift运行时版本号声明xcodegen --version输出scripts/archive.shzip 产物打包与 SHA 计算scripts/install.sh解压后的本地安装脚本Package.swiftSwiftPM 包定义及 ArtifactBundleGen 依赖声明掌握上述流程后你就可以完整复现 XcodeGen 的每一次版本发布从梳理 CHANGELOG、更新 Makefile 版本号到make release自动同步三处版本信息、make archive产出两种分发格式再到推送 tag 并创建带附件的 GitHub Release。整个过程以 Makefile 为自动化中枢配合源码中的版本常量与 CI fixture 校验构成了一个闭环、可重复、可验证的发布体系。【免费下载链接】XcodeGenA Swift command line tool for generating your Xcode project项目地址: https://gitcode.com/GitHub_Trending/xc/XcodeGen创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考