ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

stlink 版本发布全流程指南:从变更日志、版本号到 .deb/.rpm/.zip 打包与上传

stlink 版本发布全流程指南:从变更日志、版本号到 .deb/.rpm/.zip 打包与上传 嵌入式硬件开发开发工具调试器【免费下载链接】stlinkOpen source STM32 MCU programming toolset项目地址https://gitcode.com/gh_mirrors/st/stlink点击查看免费下载本篇技术指南以 stlink 官方 doc/release.md 为骨架系统讲解开源 STM32 编程工具集 stlink 的完整版本发布Release流程如何维护三份变更日志、如何更新语义化版本号.version、如何按develop → master分支模型打标签以及如何用 CPack 与交叉编译脚本生成.deb/.rpm/.zip二进制包并上传发布。读完本文你将掌握一套可直接照做的发布操作清单并理解每一步背后对应的构建系统实现CMake / CPack / Makefile为在本地复现或维护 stlink 版本发布提供依据。发布流程总览九步清单根据 doc/release.md一次完整的 stlink 发布需要依次完成以下 9 个步骤步骤操作内容涉及文件 / 命令1更新变更日志CHANGELOG.md、cmake/packaging/deb/changelog、cmake/packaging/rpm/changelog2用语义化版本x.x.x更新.version文件仓库根目录.version3用语义化版本x.x.x更新README.md中的提交徽章README.md4更新 GitHub 安全策略SECURITY.md5将develop分支合并进mastergit merge6创建并推送 git 标签与提交git tag x.x.x7生成二进制包.rpm / .deb / .zipmake package sh ./generate_binaries.sh8将包上传到项目的 Release 页面GitHub Releases9将master合并回developgit merge下面逐一对每个步骤展开并结合仓库源码说明其底层机制与注意事项。第一步更新三份变更日志发布时变更日志不是只改一处而是三个甚至四个文件保持同步CHANGELOG.md仓库根目录面向用户的主变更日志。以当前仓库为例文件开头即按版本组织例如# v1.8.1之下依次包含Release date、Updated system requirementsC 标准、cmake、libusb、libgtk 的最低版本要求、Features:与Updates changes:等小节每个条目标注对应的 PR 或 commit 编号见 CHANGELOG.md。cmake/packaging/deb/changelogDebian 包专用 changelog采用 Debian 包格式形如stlink (1.8.0) unstable; urgencymedium * Release v1.8.0 -- Nightwalker-87 stlink-org Thu, 01 Feb 2024 00:00:00 0100该文件在打包时通过CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA注入进.deb包见 cmake/packaging/deb/changelog 与 cmake/modules/cpack_config.cmake。cmake/packaging/rpm/changelogRPM 包专用 changelog通过CPACK_RPM_CHANGELOG_FILE注入.rpm包见 cmake/packaging/rpm/changelog 与 cmake/modules/cpack_config.cmake。可选debian/changelog仓库还维护了一套独立的 Debian 源包打包目录其中同样有 debian/changelog 与 debian/rules供 Debian 发行版级打包使用发布时若同步维护源包版本也需一并更新。版本号一致性约定在 cmake/modules/cpack_config.cmake 中可以看到注释明确写道“每当 upstream 版本号递增时debian_revision 应从 1 重新开始”CPACK_DEBIAN_PACKAGE_RELEASE 1RPM 侧同样使用CPACK_RPM_PACKAGE_RELEASE 1。也就是说包内的修订号按版本独立计数发布新版时应重置为 1。第二步用语义化版本更新.version文件.version文件位于仓库根目录内容就是一行语义化版本号x.x.x如1.8.1它承担着“源码包兜底版本源”的职责。构建系统如何读取版本版本号由 cmake/modules/get_version.cmake 解析逻辑分两条路径Git 仓库路径优先执行git describe --always --tag获取版本若本地源码有未提交改动会在版本后追加-dirty后缀随后剥离标签开头的v如v1.8.1→1.8.1再用正则拆出PROJECT_VERSION_MAJOR/MINOR/PATCH。若存在.version文件且与 git 版本不一致会打印Rewrite .../.version with ...!提示若.version不存在则会自动写入。无 Git 兜底路径当git未找到、.git目录不存在如从源码压缩包构建或git describe失败时直接从.version文件读取版本字符串若该文件也不存在则FATAL_ERROR终止构建。这说明发布时务必保证 git tag 与.version文件内容一致否则构建系统会检测到不一致并给出重写提示。版本号如何进入程序版本宏在构建期由 inc/version.h.in 模板生成到头文件inc/version.h其中的PROJECT_VERSION、PROJECT_VERSION_MAJOR等占位符会被替换为实际版本。同时 CMakeLists.txt 用PROJECT_VERSION_MAJOR.MINOR.PATCH设置共享库stlink-shared的SOVERSION与VERSION属性因此版本号同时决定了libstlink.so的 soname 版本。换句话说版本号的准确性直接关系到库的 ABI 版本标识。第三步更新 README 中的提交徽章发布时还需将 README.md 中的“commits”徽章更新为新的语义化版本号x.x.x。这一步属于面向用户的信息同步——徽章通常显示当前发布版本的提交计数或发布状态保证 README 首页展示的版本与本次发布一致。第四步更新安全策略 SECURITY.md发布后需同步 SECURITY.md 的“Supported Versions”表格将刚发布的版本标记为受支持:white_check_mark:并将旧版本标记为不再支持:x:。以仓库现状为例该表格的维护方式如下当前develop与1.8.1受支持1.8.0及更早版本不受支持VersionSupporteddevelop✅1.8.1✅1.8.0❌1.7.0❌...❌同时 SECURITY.md 注明由于这是开发工具集bug 修复只会应用到最新版本发现漏洞应通过常规 bug report issue 报告。第五步将develop合并进masterstlink 采用经典的双分支发布模型develop日常开发集成分支所有新功能、修复先合入这里master稳定发布分支仅存放可发布的代码状态。发布前需执行git checkout master git merge develop合并完成后master即代表本次要发布的代码快照。所有后续的标签与打包都基于该状态进行。第六步创建并推送 git 标签在master上为发布版本打上语义化标签并推送git tag x.x.x git push origin master git push origin x.x.x标签名必须与.version文件内容严格一致如1.8.1不带头字母v因为 get_version.cmake 会显式剥离标签开头的v。该标签会被git describe --always --tag捕获进而驱动 CMake 自动推导PROJECT_VERSION——所以打标签的顺序最好在打包之前完成确保包内版本正确。第七步生成二进制包.rpm / .deb / .zip发布包由两条产出线构成7.1 原生平台打包make package仓库根目录 Makefile 将 CMake 目标封装为高层命令。make package等价于在build/Release目录中执行make package见 Makefile最终驱动 CPack 生成安装包make package包产出的具体位置与格式由 cmake/modules/cpack_config.cmake 按平台分支决定Debian/Ubuntu 上打包CPACK_GENERATOR DEB;RPMRPM 需要系统安装rpm包即一次打包同时产出.deb与.rpm输出目录为build/Release/dist。.deb包的依赖、维护者、建议安装包等信息在 cmake/modules/cpack_config.cmake 中定义依赖libusb-1.0-0-dev ( 1.0.24)、cmake ( 3.19)等Suggests为libgtk-3-dev, pandoc.deb还会附带 changelog、copyright、rules、postinst 四个 Debian 控制文件见 cmake/modules/cpack_config.cmake。Windows 上打包CPACK_GENERATOR ZIP产出stlink-版本-win32.zip或交叉编译时带TOOLCHAIN_PREFIX后缀的 zip见 cmake/modules/cpack_config.cmake。其他平台不生成包。7.2 Windows 交叉编译包sh ./generate_binaries.sh官方发布文档中第 7 步写作make package sh ./generate_binaries.sh注意仓库中的实际脚本名为gen_binaries_win.sh位于仓库根目录执行时以实际文件为准make package sh ./gen_binaries_win.shgen_binaries_win.sh 内部依次完成两项 MinGW 交叉编译并产出 Windows 的.zip包x86_64 目标在build-mingw-64目录中调用cmake -DTOOLCHAIN_PREFIXx86_64-w64-mingw32 -DCMAKE_TOOLCHAIN_FILE../cmake/modules/set_toolchain.cmake -DCMAKE_SYSTEM_PROCESSORx86_64 -DCMAKE_C_FLAGS-D_WIN32 -D_AMD64_ -DSTLINK_GENERATE_GUIOFF ..随后make package生成 zip 并拷贝到build/Release/disti686 目标在build-mingw-32目录中重复上述流程TOOLCHAIN_PREFIXi686-w64-mingw32CMAKE_SYSTEM_PROCESSORi686CMAKE_C_FLAGS-D_WIN32。脚本中多处使用sudo cp拷贝产物因此执行该脚本需要 sudo 权限同时本机需已安装 MinGW 交叉编译工具链mingw-w64、autotools-dev、libtool详见 doc/compiling.md。最终所有包.deb、.rpm与两个.zip都会汇总到build/Release/dist目录。需要说明的适用前提按 doc/compiling.md 的说明MSVC 编译环境下的包生成尚未实现/测试本文所述make package的包生成流程适用于 LinuxDebian 系与 MinGW 交叉编译场景。第八步上传包到 Release 页面将build/Release/dist下生成的.rpm/.deb/.zip文件连同 CHANGELOG 摘要上传到项目的 GitHub Releases 页面填写发布说明通常包含新特性、修复与升级注意事项可直接取自 CHANGELOG.md 对应版本小节。发布说明中建议附上校验信息与目标平台说明便于用户验证下载完整性。第九步将master合并回develop发布完成后将master上的发布提交含标签、CHANGELOG 更新、.version与 SECURITY 更新等合并回develop使开发分支同步发布状态git checkout develop git merge master这一步保证了后续开发始终基于“已发布版本 新改动”的基线避免下一次发布时遗漏本次发布对版本文件与文档的改动。发布前自检清单综合全文一次发布在动手前建议逐项核对检查项通过标准三份或四份变更日志CHANGELOG.md、deb changelog、rpm changelog 均含新版本条目.version文件内容为新版本x.x.x且与 git tag 一致README 徽章已更新为x.x.xSECURITY.md新版本标记为受支持旧版本标记为不受支持分支状态develop已合并进mastermaster上打了x.x.x标签并推送打包环境LinuxDebian 系上已装rpm如需 Windows 包已装 MinGW 工具链且有 sudo 权限包产物build/Release/dist下存在.deb、.rpm及.zip文件收尾合并master已合并回develop结语stlink 的发布流程看似九步实则围绕两条主线版本信息的一致性.version、git tag、CHANGELOG、README 徽章、SECURITY 五者必须指向同一版本与打包产物的可复现性make package驱动 CPack 在 Linux 上同时产出.deb/.rpmgen_binaries_win.sh通过 MinGW 交叉编译产出 32/64 位 Windows zip。理解了 cmake/modules/get_version.cmake 的版本推导逻辑与 cmake/modules/cpack_config.cmake 的平台分支就能在发布出现版本不符、包格式缺失等问题时快速定位根因。按照本文清单逐步执行即可完成一次标准、可追溯的 stlink 版本发布。赞分享嵌入式硬件开发开发工具调试器【免费下载链接】stlinkOpen source STM32 MCU programming toolset项目地址https://gitcode.com/gh_mirrors/st/stlink点击查看免费下载相关推荐OkHttp 版本发布流程全指南从版本号变更、打 Tag 到 Maven Central 自动发布OkHttp 版本发布流程全指南从版本号变更、打 Tag 到 Maven Central 自动发布 本文以 OkHttp 仓库的 docs/releasing后端通信移动开发网络Trio 项目版本发布全流程实战SemVer 版本号、towncrier 变更日志与 PyPI 发布Trio 项目版本发布全流程实战SemVer 版本号、towncrier 变更日志与 PyPI 发布 Trio 是专注于异步并发与 I/O 的 Python后端并发编程[版本号] - YYYY-MM-DD版本号 YYYY MM DD 新功能 描述新添加的功能 问题修复 描述修复的问题 技术改进 描述技术架构改进 依赖更新 更新的依赖包列表即时通讯桌面应用前端插件系统上一篇OpenVSCode Server多用户配置终极指南10个关键步骤实现完美用户管理下一篇探索vsouza/awesome-ios中的跨平台开发iOS与其他平台代码共享创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表