TEN-framework 源码中的 curl 发布流程解析：从 git tag 到 8 周发布周期-平芜编程栈

人工智能
AI Agent
多模态
语音
AI 应用

【免费下载链接】ten-framework

Open-source framework for conversational voice AI agents

项目地址：https://gitcode.com/TEN-framework/ten-framework

导读

本文基于 ten-framework 仓库中随 curl 源码一同携带的 RELEASE-PROCEDURE.md 文档，系统梳理 curl/libcurl 官方版本的完整发布流程：包括源码仓库中的版本号处理、打包签名、官网与 GitHub 的同步发布，以及 curl 特有的 8 周发布周期与三个阶段管理策略。结合仓库内实际存在的maketgz脚本、版本头文件、RELEASE-NOTES生成工具等实现细节，帮助读者理解 curl 项目从代码提交到用户拿到 tarball 的全链路运作方式，也为主办方或自行维护 curl 分支的团队提供可参考的发布 SOP。

说明：本文所述流程为 curl 上游的官方发布规范，ten-framework 仓库以第三方依赖形式内置了 curl 源码（当前版本为 8.1.2，参见 RELEASE-NOTES 与 curlver.h 中的LIBCURL_VERSION）。仓库内相关脚本与文件路径均以third_party/curl/为根给出，便于对照阅读。

curl 发布流程总览

curl 的发布不是一个动作，而是一条跨三个仓库、四个环节的流水线：

源码仓库（curl）：准备变更、生成版本号、打 git tag、构建并签名 tarball、推送；
官网仓库（curl-www）：更新版本信息、发布公告与变更日志并打同名 tag；
GitHub：将新 tag 标记为 latest release；
通知：向 curl 官方邮件列表发送发布邮件并附上 RELEASE-NOTES。

下面按原文档的章节顺序逐一展开，并结合仓库源码补充每个步骤背后的实现细节。

在源码仓库中完成发布准备

原文档要求在 curl 源码仓库（即third_party/curl/所对应上游代码）中依次完成以下操作：

1. 运行 copyright 检查脚本

./scripts/copyright.pl

该脚本用于扫描仓库内所有受 git 管理的文件，检查版权声明是否完整、年份是否覆盖到最新改动，并纠正可能的遗漏。仓库中对应的脚本位于 scripts/copyright.pl（版本 227 行）。从源码看，脚本内置了一份skiplist，对许可证文本类文件（如COPYING、LICENSES/*.txt）不做检查，其余文件则逐行扫描copyright字样及四位年份，从而保证每个文件在发布前都带有正确的版权头。这是 curl 采用 REUSE 规范进行许可证管理的配套检查环节。

2. 校对 RELEASE-NOTES

# 生成草稿：基于上一次 "RELEASE-NOTES: synced" 提交以来的 git log 自动收集条目 ./scripts/release-notes.pl # 手动编辑 RELEASE-NOTES，删除不属于本版的条目、将变更移入对应小节 # 清理：排序条目并移除被删条目残留的引用编号 ./scripts/release-notes.pl cleanup

原文档要求"编辑RELEASE-NOTES使其准确"。仓库中的 scripts/release-notes.pl 给出了完整的辅助工作流（见脚本头部注释）：

不带参数运行时，脚本执行git log @^{/RELEASE-NOTES:.synced}..，即从最近一次以"RELEASE-NOTES: synced"为提交信息的分界点开始，收集此后所有提交，自动生成候选条目；
条目默认统一归入 bugfixes 小节（脚本无法判断语义归属），需要人工把真正的功能变更移到 changes 小节；
传入cleanup参数时，脚本扫描RELEASE-NOTES中的o ... [n]条目与[n] = url引用行，自动重新编号、剔除不再被引用的 URL 引用；
最后运行 scripts/contributors.sh 更新贡献者名单、运行scripts/delta更新开头的计数器，并以RELEASE-NOTES: synced作为提交信息提交。

仓库中当前 RELEASE-NOTES 对应 8.1.2 版本，其头部统计了"Public curl releases: 219、Command line options: 251、curl_easy_setopt() options: 302、Public functions in libcurl: 91、Contributors: 2888"，并分列了 bugfixes、known bugs、planned upcoming removals、contributors 名单及按编号索引的 issue 引用，正是该工具链产出的典型格式。

3. 更新致谢名单

# 更新 docs/THANKS ./scripts/contrithanks.sh

原文档要求更新docs/THANKS。该文件在本仓库中的位置是 docs/THANKS，配套的贡献者名单生成脚本为 scripts/contrithanks.sh。它根据 git 历史生成/更新致谢名单，与 RELEASE-NOTES 中的 contributors 部分相互印证。

4. 提交变更并打 GPG 签名的 git tag

git commit # 确保所有相关变更已提交到 master 分支 git tag -a -s curl-7_34_0 # -a 表示带注释的 tag；-s 表示 GPG 签名

原文档特别强调两点：

tag 命名规范：使用curl-前缀，版本号中的点改为下划线（如 7.34.0 →curl-7_34_0），而不是直接沿用形如v7.34.0的常见命名；
必须签名：使用-a标注注释、使用-s进行 GPG 签名，保证发布物的完整性可被校验。

5. 用 maketgz 构建发布 tarball

./maketgz 7.34.0

原文档强调：必须在安装了正确 autotools 等工具链的机器上执行，因为生成的 tarball 就是大多数 *nix 用户后续实际使用与构建的产物。

仓库中的 maketgz（shell 脚本，225 行）完整实现了这一步，可提炼出以下关键动作：

版本号解析与头文件更新：脚本接收$1作为版本号（格式必须为z.y.z），用cut拆出 major/minor/patch，并用perl计算出 24 位十六进制数值版本号：

major=`echo $libversion | cut -d. -f1 | sed -e "s/[^0-9]//g"` minor=`echo $libversion | cut -d. -f2 | sed -e "s/[^0-9]//g"` patch=`echo $libversion | cut -d. -f3 | cut -d- -f1 | sed -e "s/[^0-9]//g"` numeric=`perl -e 'printf("%02x%02x%02x\n", '"$major, $minor, $patch);"`

随后通过sed批量改写三个版本载体文件：

include/curl/curlver.h：更新LIBCURL_VERSION、LIBCURL_VERSION_NUM（如0x080102）、LIBCURL_VERSION_MAJOR/MINOR/PATCH与LIBCURL_TIMESTAMP（日期戳取自date +"%F"）；
src/tool_version.h：更新命令行工具版本；
lib/libcurl.plist：更新 macOS 平台属性列表版本。

这一点可以与本仓库中 include/curl/curlver.h 实际内容相互印证：文件头部定义了LIBCURL_VERSION "8.1.2-DEV"、LIBCURL_VERSION_NUM 0x080102以及LIBCURL_TIMESTAMP "[unreleased]"，注释明确说明 timestamp 不存入 git，而是在打包时由maketgz写入真实日期——这正是该脚本第 81～91 行所做的工作。

构建产物链：脚本依次生成四种压缩格式的源码包：

产物	生成方式
`curl-$version.tar.gz`	`make -sj dist VERSION=$version`
`curl-$version.tar.bz2`	`gzip -dc $targz \| bzip2 --best`
`curl-$version.tar.xz`	`gzip -dc $targz \| xz -6e -`
`curl-$version.zip`	解包 tar.gz 后重新`zip -@`打包

此外脚本还会：清理遗留的*.dist文件、重新执行./config.status --recheck强制更新 VERSION、必要时运行automake --include-deps、调用 scripts/updatemanpages.pl 更新 man 手册中的版本号与日期、执行make -s vc-ide更新 IDE 工程文件，并通过git log ... | ./scripts/log2changes.pl（见 scripts/log2changes.pl，按月份缩写格式化日期、将提交信息折行排版）生成CHANGES.dist变更日志。

6. 推送提交与 tag

git push git push origin curl-7_34_0

将源码仓库的 commits 与新 tag 推送到远程，作为后续打包与官网同步的基础。

7. GPG 签名四个 tarball

脚本结束时会在终端打印出签名建议命令：

gpg -b -a curl-7.34.0.tar.gz && gpg -b -a curl-7.34.0.tar.bz2 && \ gpg -b -a curl-7.34.0.zip && gpg -b -a curl-7.34.0.tar.xz

即对四种压缩包各自生成独立的 ASCII 格式 GPG 签名文件（.asc）。

8. 上传 8 个产物到下载目录

原文档指出最终需要上传8 个文件：4 个压缩包 + 4 个对应的 GPG 签名文件，统一放入主下载目录，供全球用户与镜像站拉取。

在 curl-www 官网仓库同步发布

源码发布完成后，需要在 curl 官网对应的curl-www仓库中完成以下同步：

编辑Makefile：更新版本号与发布日期；
编辑_newslog.html：发布新版本公告；
编辑_changes.html：把 RELEASE-NOTES 中的变更与 bugfix 条目插入其中；
提交所有本地变更；
以与源码仓库相同的 tag 名打 tag（保证两个仓库 tag 一一对应、可追溯）；
确保所有变更提交并推送到 master 分支——此后官网内容会自动更新。

这一步体现了 curl 网站即代码的管理方式：发布信息全部通过 git 维护，推送 master 即触发线上更新，无需手工部署。

在 GitHub 上标记最新版本

# 在 GitHub Releases 页面操作 # 将刚创建的 release tag 编辑为 "latest release"

原文档要求进入 GitHub 的 Releases 页面，把新打的 tag 标记为 latest release。该操作让下载入口、release 通知与源码 tag 保持一致，方便开发者通过 GitHub 途径获取版本信息。

发布通知：邮件列表与 RELEASE-NOTES

# 向 curl-users、curl-announce、curl-library 三个邮件列表发送邮件 # 并将 RELEASE-NOTES 全文插入邮件正文

原文档要求将 RELEASE-NOTES 作为邮件正文发送给三个面向不同受众的官方邮件列表：

curl-users：面向最终用户；
curl-announce：面向关注版本发布的订阅者；
curl-library：面向 libcurl 开发与集成者。

这一步与仓库中 RELEASE-NOTES 的编写规范闭环：文档要求"编辑 RELEASE-NOTES 使其准确"，而发布邮件直接复用这份文件，因此其质量直接决定发布公告的可读性。

发布庆祝

原文档以一句轻松的话收尾："在庆祝活动中，适量饮用合适的饮料是被鼓励的。"这句话并非流程的一部分，而是 curl 项目对发布这种高强度协作周期的幽默注脚，通常在阅读与引用时可作为流程完成后的收束语。

curl 的 8 周发布周期与三阶段管理

原文档后半部分定义了 curl 的发布调度机制，这是理解 curl 版本节奏的核心：

基本节奏

curl 正常情况下每 8 周（56 天）发布一次，发布日通常选在周三。如果出现重要问题，可以插入计划外发布或调整发布日期。

三个明确阶段

每个 56 天的发布周期被划分为三个互不重叠的阶段：

阶段	时长	允许合并的内容
冷却期（cool down）	发布后前 10 个日历日	仅 bug 修复，不合并新功能；若出现回归，可能跟进一个补丁版本
功能窗口（feature window）	接下来的 3 周（21 天）	允许合入 curl/libcurl 的新功能与改动；一旦合入新功能，下一次发布的 minor 版本号即递增
功能冻结（feature freeze）	接下来的 25 天	不再合入任何功能或改动，只聚焦修 bug 与打磨，确保待发布版本稳固

从源码角度看，这套节奏直接映射到版本号的增长规则：maketgz只处理z.y.z三段式版本，而"功能窗口内合入新特性 → minor 号 +1"正是 curl 采用"语义化向前兼容"版本策略的调度体现；RELEASE-NOTES 中每次发布都会统计的 release 计数与选项计数，也服务于发布前对版本状态的自检。

日期调整规则

如果未来的发布日期落在"糟糕的日期"上——例如处于公共节假日中间，或主要发布经理不可用——发布日期可以向前或向后移动整整一周，并且需要提前广而告之。

关键问题的补丁发布

curl 允许在任意时刻打破发布周期，进行 patch release，只要出现"足够关键"的问题。原文档明确指出：

没有对"关键性"给出精确定义，但若某个问题对足够大规模的用户群体造成严重困扰或安全影响，就可能够格；
如果认为某个问题够格，应在curl-library 邮件列表上提出并推动。

这体现了 curl 以安全与稳定性为先的发布哲学：8 周周期是常态，但安全漏洞等紧急情况永远优先。

计划内发布日期示例

原文档给出（截至撰写时的）后续计划发布日：

May 17, 2023
July 19, 2023
September 6, 2023
November 1, 2023
December 27, 2023
February 21, 2024
April 17, 2024
June 12, 2024

这些日期按上述规则推算：约每 8 周一个周三，个别日期因节假日等因素平移一周。读者可将其作为验证"56 天周期 + 周三发布 + 必要时整周平移"规则的实例来理解，而非当前有效的发布日历（仓库内 curl 版本已演进至 8.1.2）。

从仓库源码看发布工具链的落点

为了让读者能对照源码进一步深入，这里汇总本仓库中与发布流程直接相关的文件与各自职责：

docs/RELEASE-PROCEDURE.md：发布流程规范本身，本文的骨架来源；
maketgz：版本写入、tarball 生成与 GPG 签名提示的一键脚本；
include/curl/curlver.h：版本宏定义（LIBCURL_VERSION、LIBCURL_VERSION_NUM、LIBCURL_TIMESTAMP等），是maketgz的主要改写对象；
RELEASE-NOTES：发布说明的最终载体，也是邮件公告的正文素材；
scripts/release-notes.pl：从 git log 生成并清理 RELEASE-NOTES 条目的工具；
scripts/copyright.pl：发布前的版权声明完整性检查；
scripts/contrithanks.sh 与 docs/THANKS：贡献者致谢名单维护；
scripts/log2changes.pl：将 git log 排版为CHANGES变更日志；
scripts/updatemanpages.pl：发布时更新 man 手册中的版本信息。

可以看出，curl 把"发布"拆解为一组可复现、可审计的脚本化步骤：版本号只在maketgz一处写入并派生到各文件，避免手工编辑遗漏；tag 与 tarball 全部强制 GPG 签名；文档、官网、邮件三路发布共用同一份 RELEASE-NOTES。对于需要自行维护 curl 分支或借鉴开源项目发布管理的团队，这套流程与脚本都是可以直接参考的范本。

小结

curl 的发布流程是一条"源码打标打包 → 官网同步 → GitHub 标记 → 邮件通知"的完整链路，其背后是严格的 8 周三阶段节奏（10 天冷却期 → 21 天功能窗口 → 25 天功能冻结）与"关键问题可随时打破周期"的应急机制。通过对照本仓库内实际存在的maketgz、release-notes.pl、copyright.pl等工具与版本头文件，可以确认：文档描述的每个步骤都有具体实现支撑，版本号、产物格式、签名方式等细节均可逐一在源码中定位验证。