拓冰网站定制 
CopyQ 版本发布全流程指南从 CHANGES 更新到多平台产物签名发布【免费下载链接】CopyQClipboard manager with advanced features项目地址: https://gitcode.com/gh_mirrors/co/CopyQCopyQ 是一个功能丰富的跨平台剪贴板管理器官方描述为 Clipboard manager with advanced features。本文以仓库根目录下的 RELEASE.md 为骨架结合仓库内的发布脚本、CI 工作流与元数据文件系统讲解 CopyQ 从「敲定新版本号」到「在 GitHub 上发布草稿、签名校验、同步 Flathub 与 SourceForge」的完整发布链路。读完本文你将掌握 CopyQ 官方发布流程中每个步骤的精确命令、底层脚本逻辑以及各平台构建产物的命名与用途可直接照此流程操作一次完整发布。发布流程总览CopyQ 的发布遵循一个清晰的两段式模型代码侧准备更新变更日志并提升版本号提交后推送带标签--follow-tags的提交产物侧发布运行draft-release.sh脚本由脚本自动化完成「创建 GitHub 草稿发布 → 等待 CI 构建 → 下载产物 → 生成 SHA-512 校验和并签名 → 上传全部资产」的闭环最后再由维护者手动完成 Flatpak、SourceForge 与公告的收尾工作。整个流程对应仓库根目录的三个关键文件阶段入口仓库位置版本号与变更日志utils/bump_version.shutils/bump_version.sh自动化草稿发布utils/github/draft-release.shutils/github/draft-release.sh变更日志正文CHANGES.mdCHANGES.md第一步更新版本与变更日志1.1 更新 CHANGES.md发布的第一步是更新 CHANGES.md需要逐个过一遍自上一个发布标签以来的所有提交把新功能Added、修复Fixed、变更Changed等分类整理进文件顶部。例如当前仓库中CHANGES.md的顶部段落就是以# 16.0.0开头其下列出## Added、## Fixed等小节。一个容易被忽略但脚本强制的约束是CHANGES.md的第一行必须恰好等于# 新版本号注意不带v前缀。无论是bump_version.sh还是draft-release.sh都会先校验这一行不一致会直接报错退出。因此顺序必须是先更新 CHANGES.md再执行版本号脚本。1.2 提升版本号bump_version.sh在确保 CHANGES.md 已更新后执行utils/bump_version.sh 14.0.0该脚本set -euo pipefail严格模式依次执行以下检查与替换校验版本格式check_version_format要求版本号匹配^[0-9]\.[0-9]\.[0-9]$即严格的三段式MAJOR.MINOR.PATCH否则提示 Expected version format is MAJOR.MINOR.PATCH 并退出校验变更日志check_changes读取CHANGES.md首行必须等于# $version否则提示 Update CHANGES.md first更新版本头文件通过fix_version_file将 src/version.cmake 中的set(copyq_version …)替换为新版本更新插件 ID通过fix_itemwidget将 src/item/itemwidget.h 中的插件加载器 IDcom.github.hluk.copyq.itemloader/版本号一并更新保证插件版本与应用版本保持一致更新 AppData 元数据fix_appdata操作 shared/com.github.hluk.copyq.metainfo.xml删除旧的同名release节点新增release version新版本 date当日日期 /插入到releases段并通过appstream-util validate-relax --nonet校验合法性提交与打标签最后执行git commit -a -m v$version、git tag -s -a -m v$version v$version完成带 GPG 签名的注释标签创建并git show展示结果确认。值得留意的是fix_file的防御性设计替换完成后会反查文件确认替换结果失败即退出避免改了但没改对的静默错误。1.3 版本号的运行时获取从源码结构看src/version.cmake 说明了版本号最终如何进入构建产物CMake 会优先尝试git describe --tags若成功则剥离标签的v前缀并把v14.0.0-4-g1175475d这种提交数短哈希后缀改写为可排序的14.0.0.4-g1175475d格式在无完整 Git 历史如浅克隆或没有 Git 的环境下则回退读取GITHUB_REF环境变量从refs/tags/vX.Y.Z中提取干净版本号。这也解释了 CI 中为何需要fetch-depth: 0拉取完整历史——可排序的版本字符串依赖git describe。1.4 推送变更与标签版本提交与标签就绪后推送到所有远程仓库for r in origin gitlab; do git push --follow-tags $r master || break; done--follow-tags会连带推送标签而|| break保证任一远程推送失败即中止循环避免后续远程状态不一致。注意官方维护者的远程配置是origin与gitlab两个其他贡献者应按自己的远程名调整。第二步起草 GitHub Release2.1 脚本调用方式utils/github/draft-release.sh 14.0.0脚本要求VERSION参数与最新的 Git 标签严格一致内部用git describe --tags --abbrev0 HEAD取最新标签并校验为v$version同时再次确认CHANGES.md首行。运行前需要准备好已认证的ghCLI、带完整标签的 Git 仓库、以及用于签名的cosign。2.2 自动化完成的工作draft-release.sh是发布创建的唯一入口CI 工作流build-linux.yml、build-macos.yml、build-windows.yml只负责构建并把产物通过actions/upload-artifact存为 workflow artifacts由脚本统一收口。其内部步骤校验版本 / 标签 / CHANGES.md三者任何一个不匹配立即die退出提取变更日志正文用awk解析CHANGES.md取出从# $version小节到下一个#小节之间的内容去掉首尾空行作为 GitHub Release 的说明正文创建源码压缩包git archive --formattar.gz --prefixCopyQ-$version/ --output... $tag以CopyQ-版本.tar.gz命名产物以CopyQ-版本/为目录前缀保证解压后目录干净等待 CI 构建脚本依次针对build-linux.yml、build-macos.yml、build-windows.yml三个工作流用gh run list --workflow … --commit tag 的 commit SHA找到对应运行 ID再用gh run watch --exit-status --interval 30阻塞等待其成功任一工作流失败即中止下载构建产物gh run download拉取各工作流产物并做拍平处理把子目录中的文件移动到工作目录已存在的文件跳过核验产物齐全脚本内置了 5 个预期资产清单见下文文件不全则报错并列出工作目录内容生成校验和并签名对源码包 全部二进制资产执行sha512sum生成checksums-sha512.txt再用cosign sign-blob签名会弹出浏览器进行 OIDC 认证随即用cosign verify-blob验证签名、--certificate-identityhlukemail.cz、--certificate-oidc-issuerhttps://github.com/login/oauth创建或更新草稿发布gh release create $tag --draft --title $version --notes $changelog_body若该标签的 Release 已存在则改为gh release edit --draft仅更新标题与正文一次性上传全部资产源码包 5 个二进制产物 校验和 cosign.bundle使用--clobber允许覆盖重传。2.3 幂等性设计脚本最实用的特性是幂等每个阶段都会先检查是否已完成已存在的文件会跳过。因此中途中断例如网络波动或 cosign 认证超时后用相同的工作目录重新运行即可断点续传utils/github/draft-release.sh 14.0.0 ./release-14.0.0第二个参数WORKDIR默认是./release-版本所有源码包、CI 产物、校验和文件都沉淀在该目录重跑时无需重新下载已存在的资产。2.4 CI 自动附加的发布产物由 GitHub Actions 构建并附加到发布草稿的资产及来源平台产物命名构建工作流Windows 安装程序copyq-版本-setup.exeInno Setup 打包见 shared/copyq.issbuild-windows.ymlWindows 便携版copyq-版本.zip同上macOS Intel DMGCopyQ-版本-macos-13.dmg部署目标 macOS 13build-macos.ymlmacOS Apple Silicon DMGCopyQ-版本-macos-12-m1.dmgarm64 架构同上Linux AppImageCopyQ-版本-x86_64.AppImagebuild-linux.yml从 CMakePresets.json 可以看到对应的构建预设AppImage-Release预设开启WITH_APPIMAGE与WITH_TESTS、WITH_QCA_ENCRYPTIONmacOS-13与macOS-13-m1预设分别对应 Intel 与 Apple SiliconCMAKE_OSX_ARCHITECTURES: arm64Windows预设用于 MSVC 构建。Linux 侧还借助 linuxdeploy 及其 qt/appimage 插件打包并手动把 KF6、Wayland 与 QCA ossl 等插件目录补进 AppImage见 build-linux.yml 的 Create AppImage 步骤。第三步构建 Flatpak 包Release 草稿创建完成后还需要更新 Flatpak 发布渠道Flathub 上的com.github.hluk.copyq包。仓库内保留了 Flatpak 清单示例 shared/flatpak/com.github.hluk.copyq.json当前示例指向较旧标签实际发布时应改为最新 tag 与 commit。官方流程为在com.github.hluk.copyq.json文件中更新tag与commit字段为新版本的标签名与对应提交哈希推送到你自己的 fork向 Flathub 上游仓库发起 Pull Request等待构建完成flathubbot 会在 PR 评论区反馈构建结果构建通过后合并变更。清单文件的典型结构仓库示例runtime使用org.kde.Platform、sdk使用org.kde.Sdkfinish-args放开 X11/Wayland 套接字、org.kde.StatusNotifierWatcherD-Bus 名称、IPC 共享与 DRI 设备用于托盘图标与剪贴板/图像能力modules中以cmake-ninja构建系统拉取 CopyQ 源码config-opts传入-DCMAKE_BUILD_TYPERelease与-DICON_NAMEcom.github.hluk.copyq。第四步发布与后续收尾草稿发布审查无误后在 GitHub 上将其正式发布Publish。之后还有三个手工步骤draft-release.sh运行结束时也会提示这些 Remaining manual steps同步 SourceForge把各平台的安装包与二进制文件上传到 CopyQ 在 SourceForge 的项目文件区https://sourceforge.net/projects/copyq/files/更新 Flathub若尚未在第三步完成撰写发布公告发送到 CopyQ 的 Google Grouphttps://groups.google.com/forum/#!forum/copyq向用户通告新版本的主要变化。常见失败点与排查建议结合两个脚本的显式校验逻辑发布过程中最容易踩的坑集中在CHANGES.md 首行与版本号不一致两个脚本都会在开头校验# 版本号务必先改 CHANGES 再执行 bump版本号格式错误必须是MAJOR.MINOR.PATCH三段数字bump_version.sh直接拒绝最新标签与 VERSION 参数不匹配draft-release.sh用git describe --tags --abbrev0取最新标签发布前确认本地已git fetch --tagsCI 工作流失败任一平台的 workflow run 失败都会让脚本中止可先单独查看对应工作流日志修复后再重跑预期产物缺失五个平台资产必须全部下载齐全脚本会明确列出工作目录内容辅助排查签名中断cosign 的浏览器 OIDC 认证中断时重跑同一 WORKDIR 即可跳过已完成的下载与校验阶段。总结CopyQ 的发布流程是一个人工编排 脚本闭环 平台分发的组合bump_version.sh负责把版本号原子地写进 CMake 配置、插件 ID 与 AppStream 元数据并打上签名标签draft-release.sh把 GitHub Release 草稿、CI 产物收集、SHA-512 校验与 cosign 签名全部自动化且具备可断点续传的幂等性最后由维护者完成 Flathub、SourceForge 与公告的分发收尾。理解这一流程你既能照着 RELEASE.md 完整发布一个新版本也能从 utils/github/draft-release.sh 的源码中借鉴校验—等待—下载—签名—上传的自动化发布范式。【免费下载链接】CopyQClipboard manager with advanced features项目地址: https://gitcode.com/gh_mirrors/co/CopyQ创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CopyQ 版本发布全流程指南：从 CHANGES 更新到多平台产物签名发布
CopyQ 版本发布全流程指南从 CHANGES 更新到多平台产物签名发布【免费下载链接】CopyQClipboard manager with advanced features项目地址: https://gitcode.com/gh_mirrors/co/CopyQCopyQ 是一个功能丰富的跨平台剪贴板管理器官方描述为 Clipboard manager with advanced features。本文以仓库根目录下的 RELEASE.md 为骨架结合仓库内的发布脚本、CI 工作流与元数据文件系统讲解 CopyQ 从「敲定新版本号」到「在 GitHub 上发布草稿、签名校验、同步 Flathub 与 SourceForge」的完整发布链路。读完本文你将掌握 CopyQ 官方发布流程中每个步骤的精确命令、底层脚本逻辑以及各平台构建产物的命名与用途可直接照此流程操作一次完整发布。发布流程总览CopyQ 的发布遵循一个清晰的两段式模型代码侧准备更新变更日志并提升版本号提交后推送带标签--follow-tags的提交产物侧发布运行draft-release.sh脚本由脚本自动化完成「创建 GitHub 草稿发布 → 等待 CI 构建 → 下载产物 → 生成 SHA-512 校验和并签名 → 上传全部资产」的闭环最后再由维护者手动完成 Flatpak、SourceForge 与公告的收尾工作。整个流程对应仓库根目录的三个关键文件阶段入口仓库位置版本号与变更日志utils/bump_version.shutils/bump_version.sh自动化草稿发布utils/github/draft-release.shutils/github/draft-release.sh变更日志正文CHANGES.mdCHANGES.md第一步更新版本与变更日志1.1 更新 CHANGES.md发布的第一步是更新 CHANGES.md需要逐个过一遍自上一个发布标签以来的所有提交把新功能Added、修复Fixed、变更Changed等分类整理进文件顶部。例如当前仓库中CHANGES.md的顶部段落就是以# 16.0.0开头其下列出## Added、## Fixed等小节。一个容易被忽略但脚本强制的约束是CHANGES.md的第一行必须恰好等于# 新版本号注意不带v前缀。无论是bump_version.sh还是draft-release.sh都会先校验这一行不一致会直接报错退出。因此顺序必须是先更新 CHANGES.md再执行版本号脚本。1.2 提升版本号bump_version.sh在确保 CHANGES.md 已更新后执行utils/bump_version.sh 14.0.0该脚本set -euo pipefail严格模式依次执行以下检查与替换校验版本格式check_version_format要求版本号匹配^[0-9]\.[0-9]\.[0-9]$即严格的三段式MAJOR.MINOR.PATCH否则提示 Expected version format is MAJOR.MINOR.PATCH 并退出校验变更日志check_changes读取CHANGES.md首行必须等于# $version否则提示 Update CHANGES.md first更新版本头文件通过fix_version_file将 src/version.cmake 中的set(copyq_version …)替换为新版本更新插件 ID通过fix_itemwidget将 src/item/itemwidget.h 中的插件加载器 IDcom.github.hluk.copyq.itemloader/版本号一并更新保证插件版本与应用版本保持一致更新 AppData 元数据fix_appdata操作 shared/com.github.hluk.copyq.metainfo.xml删除旧的同名release节点新增release version新版本 date当日日期 /插入到releases段并通过appstream-util validate-relax --nonet校验合法性提交与打标签最后执行git commit -a -m v$version、git tag -s -a -m v$version v$version完成带 GPG 签名的注释标签创建并git show展示结果确认。值得留意的是fix_file的防御性设计替换完成后会反查文件确认替换结果失败即退出避免改了但没改对的静默错误。1.3 版本号的运行时获取从源码结构看src/version.cmake 说明了版本号最终如何进入构建产物CMake 会优先尝试git describe --tags若成功则剥离标签的v前缀并把v14.0.0-4-g1175475d这种提交数短哈希后缀改写为可排序的14.0.0.4-g1175475d格式在无完整 Git 历史如浅克隆或没有 Git 的环境下则回退读取GITHUB_REF环境变量从refs/tags/vX.Y.Z中提取干净版本号。这也解释了 CI 中为何需要fetch-depth: 0拉取完整历史——可排序的版本字符串依赖git describe。1.4 推送变更与标签版本提交与标签就绪后推送到所有远程仓库for r in origin gitlab; do git push --follow-tags $r master || break; done--follow-tags会连带推送标签而|| break保证任一远程推送失败即中止循环避免后续远程状态不一致。注意官方维护者的远程配置是origin与gitlab两个其他贡献者应按自己的远程名调整。第二步起草 GitHub Release2.1 脚本调用方式utils/github/draft-release.sh 14.0.0脚本要求VERSION参数与最新的 Git 标签严格一致内部用git describe --tags --abbrev0 HEAD取最新标签并校验为v$version同时再次确认CHANGES.md首行。运行前需要准备好已认证的ghCLI、带完整标签的 Git 仓库、以及用于签名的cosign。2.2 自动化完成的工作draft-release.sh是发布创建的唯一入口CI 工作流build-linux.yml、build-macos.yml、build-windows.yml只负责构建并把产物通过actions/upload-artifact存为 workflow artifacts由脚本统一收口。其内部步骤校验版本 / 标签 / CHANGES.md三者任何一个不匹配立即die退出提取变更日志正文用awk解析CHANGES.md取出从# $version小节到下一个#小节之间的内容去掉首尾空行作为 GitHub Release 的说明正文创建源码压缩包git archive --formattar.gz --prefixCopyQ-$version/ --output... $tag以CopyQ-版本.tar.gz命名产物以CopyQ-版本/为目录前缀保证解压后目录干净等待 CI 构建脚本依次针对build-linux.yml、build-macos.yml、build-windows.yml三个工作流用gh run list --workflow … --commit tag 的 commit SHA找到对应运行 ID再用gh run watch --exit-status --interval 30阻塞等待其成功任一工作流失败即中止下载构建产物gh run download拉取各工作流产物并做拍平处理把子目录中的文件移动到工作目录已存在的文件跳过核验产物齐全脚本内置了 5 个预期资产清单见下文文件不全则报错并列出工作目录内容生成校验和并签名对源码包 全部二进制资产执行sha512sum生成checksums-sha512.txt再用cosign sign-blob签名会弹出浏览器进行 OIDC 认证随即用cosign verify-blob验证签名、--certificate-identityhlukemail.cz、--certificate-oidc-issuerhttps://github.com/login/oauth创建或更新草稿发布gh release create $tag --draft --title $version --notes $changelog_body若该标签的 Release 已存在则改为gh release edit --draft仅更新标题与正文一次性上传全部资产源码包 5 个二进制产物 校验和 cosign.bundle使用--clobber允许覆盖重传。2.3 幂等性设计脚本最实用的特性是幂等每个阶段都会先检查是否已完成已存在的文件会跳过。因此中途中断例如网络波动或 cosign 认证超时后用相同的工作目录重新运行即可断点续传utils/github/draft-release.sh 14.0.0 ./release-14.0.0第二个参数WORKDIR默认是./release-版本所有源码包、CI 产物、校验和文件都沉淀在该目录重跑时无需重新下载已存在的资产。2.4 CI 自动附加的发布产物由 GitHub Actions 构建并附加到发布草稿的资产及来源平台产物命名构建工作流Windows 安装程序copyq-版本-setup.exeInno Setup 打包见 shared/copyq.issbuild-windows.ymlWindows 便携版copyq-版本.zip同上macOS Intel DMGCopyQ-版本-macos-13.dmg部署目标 macOS 13build-macos.ymlmacOS Apple Silicon DMGCopyQ-版本-macos-12-m1.dmgarm64 架构同上Linux AppImageCopyQ-版本-x86_64.AppImagebuild-linux.yml从 CMakePresets.json 可以看到对应的构建预设AppImage-Release预设开启WITH_APPIMAGE与WITH_TESTS、WITH_QCA_ENCRYPTIONmacOS-13与macOS-13-m1预设分别对应 Intel 与 Apple SiliconCMAKE_OSX_ARCHITECTURES: arm64Windows预设用于 MSVC 构建。Linux 侧还借助 linuxdeploy 及其 qt/appimage 插件打包并手动把 KF6、Wayland 与 QCA ossl 等插件目录补进 AppImage见 build-linux.yml 的 Create AppImage 步骤。第三步构建 Flatpak 包Release 草稿创建完成后还需要更新 Flatpak 发布渠道Flathub 上的com.github.hluk.copyq包。仓库内保留了 Flatpak 清单示例 shared/flatpak/com.github.hluk.copyq.json当前示例指向较旧标签实际发布时应改为最新 tag 与 commit。官方流程为在com.github.hluk.copyq.json文件中更新tag与commit字段为新版本的标签名与对应提交哈希推送到你自己的 fork向 Flathub 上游仓库发起 Pull Request等待构建完成flathubbot 会在 PR 评论区反馈构建结果构建通过后合并变更。清单文件的典型结构仓库示例runtime使用org.kde.Platform、sdk使用org.kde.Sdkfinish-args放开 X11/Wayland 套接字、org.kde.StatusNotifierWatcherD-Bus 名称、IPC 共享与 DRI 设备用于托盘图标与剪贴板/图像能力modules中以cmake-ninja构建系统拉取 CopyQ 源码config-opts传入-DCMAKE_BUILD_TYPERelease与-DICON_NAMEcom.github.hluk.copyq。第四步发布与后续收尾草稿发布审查无误后在 GitHub 上将其正式发布Publish。之后还有三个手工步骤draft-release.sh运行结束时也会提示这些 Remaining manual steps同步 SourceForge把各平台的安装包与二进制文件上传到 CopyQ 在 SourceForge 的项目文件区https://sourceforge.net/projects/copyq/files/更新 Flathub若尚未在第三步完成撰写发布公告发送到 CopyQ 的 Google Grouphttps://groups.google.com/forum/#!forum/copyq向用户通告新版本的主要变化。常见失败点与排查建议结合两个脚本的显式校验逻辑发布过程中最容易踩的坑集中在CHANGES.md 首行与版本号不一致两个脚本都会在开头校验# 版本号务必先改 CHANGES 再执行 bump版本号格式错误必须是MAJOR.MINOR.PATCH三段数字bump_version.sh直接拒绝最新标签与 VERSION 参数不匹配draft-release.sh用git describe --tags --abbrev0取最新标签发布前确认本地已git fetch --tagsCI 工作流失败任一平台的 workflow run 失败都会让脚本中止可先单独查看对应工作流日志修复后再重跑预期产物缺失五个平台资产必须全部下载齐全脚本会明确列出工作目录内容辅助排查签名中断cosign 的浏览器 OIDC 认证中断时重跑同一 WORKDIR 即可跳过已完成的下载与校验阶段。总结CopyQ 的发布流程是一个人工编排 脚本闭环 平台分发的组合bump_version.sh负责把版本号原子地写进 CMake 配置、插件 ID 与 AppStream 元数据并打上签名标签draft-release.sh把 GitHub Release 草稿、CI 产物收集、SHA-512 校验与 cosign 签名全部自动化且具备可断点续传的幂等性最后由维护者完成 Flathub、SourceForge 与公告的分发收尾。理解这一流程你既能照着 RELEASE.md 完整发布一个新版本也能从 utils/github/draft-release.sh 的源码中借鉴校验—等待—下载—签名—上传的自动化发布范式。【免费下载链接】CopyQClipboard manager with advanced features项目地址: https://gitcode.com/gh_mirrors/co/CopyQ创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考