大数据数据分析后端【免费下载链接】datafusionApache DataFusion SQL Query Engine项目地址https://gitcode.com/gh_mirrors/datafu/datafusion点击查看免费下载Apache DataFusion 作为 Apache 软件基金会ASF顶级项目其正式发布遵循严格的签名源码 tarball PMC 投票 crates.io 再发布治理模型。本文以仓库中维护者视角的发布指南 dev/release/README.md 为主体结合dev/release/目录下create-tarball.sh、verify-release-candidate.sh、release-tarball.sh、generate-changelog.py等自动化脚本的源码实现完整讲解从创建branch-NN发布分支、生成与签名 RC 构件、发起 72 小时社区投票、正式归档发布到 40 个 crate 依序发布到 crates.io 的全流程。读完本文你将掌握 Apache DataFusion 发布经理Release Manager所需的完整操作链并理解每步背后的脚本实现原理。发布流程概览贡献者视角与维护者视角的分工DataFusion 的发布相关工作分成两层贡献者视角发布分支与 backport回移植策略见 docs/source/contributor-guide/release_management.md。该文档说明 DataFusion 每月左右发布一次包含破坏性 API 变更的主版本major release补丁版本patch release按需发布新功能落在main分支发布从branch-NN分支切出仅目标明确、风险低的修复允许进入发布分支。维护者视角本文主体dev/release/README.md面向拥有提交权限的维护者覆盖创建发布候选Release CandidateRC并执行完整发布流程。作为 Apache 治理模型的一部分官方发布由经 PMC 批准的签名源码 tarball 构成代码批准后再发布到 crates.io。这意味着 DataFusion 的 Rust crate 版本不是直接推到 crates.io 的而是必须等待源码 tarball 通过投票后才能发布。发布前置条件1. 为apache仓库添加 git remote下述指令假定上游仓库gitgithub.com:apache/datafusion.git配置为名为apache的 remotegit remote add apache gitgithub.com:apache/datafusion.git后续所有发布步骤都基于该 remote 操作确保与 Apache 官方仓库保持同步。2. 创建 GitHub Personal Access TokenPATchangelog 自动化脚本需要 GitHub Personal Access Token。如果没有请创建带repo权限的 token。该 token 通过环境变量GITHUB_TOKEN提供给脚本脚本底层使用 PyGitHub 库调用 GitHub REST API见下文 changelog 一节。若未设置 tokengenerate-changelog.py会因 GitHub API 限流403 rate limit exceeded而报错这是最常见的坑之一。3. 将 GPG 公钥加入 SVN KEYS 文件若你负责发布最终 tarball你的 GPG 公钥必须出现在以下两个 SVN 文件分别对应开发区与正式发布区https://dist.apache.org/repos/dist/dev/datafusion/KEYShttps://dist.apache.org/repos/dist/release/datafusion/KEYS提交者可用 Subversion 客户端配合 ASF 账号添加签名密钥$ svn co https://dist.apache.org/repos/dist/dev/datafusion $ cd datafusion $ editor KEYS # 在此添加你的密钥 $ svn ci KEYS # 提交变更按照 KEYS 文件头部的说明追加密钥追加示例(gpg --list-sigs John Doe gpg --armor --export John Doe) KEYS svn commit KEYS -m Add key for John DoeGPG 密钥是整个签名体系的基础RC 构件、最终 tarball 均需用其签名验证脚本也会下载 KEYS 文件并gpg --import后校验签名。发布流程逐步详解Step by Step1. 创建发布分支在apache仓库中从main切出新的发布分支。例如为50.x.y发布系列创建branch-50git fetch apache # 确保最新 git checkout apache/main # 检出当前最新开发分支 git checkout -b branch-50 # 创建本地分支 git push -u apache branch-50 # 推送到 apache remote发布系列名规则为branch-NN对应主版本号。补丁版本如50.1.0、50.2.0从同一branch-50切出。2. 提交更新发布版本的 PR手动将根目录Cargo.toml中的 DataFusion 版本更新为新发布版本并通过以下命令确保Cargo.lock同步更新cargo check -p datafusion用户文档中还有多处引用当前版本号需要同步手动更新目前包括docs/source/download.mddocs/source/user-guide/configs.mddocs/source/user-guide/crate-configuration.mddocs/source/user-guide/example-usage.md然后提交变更并创建针对发布分支branch-N的 PRgit commit -a -m Update version3. 保护发布分支为防止发布候选分支被意外合并创建针对main的 PR 来添加分支保护git fetch apache git checkout -b protect_branch_50 ./dev/release/add-branch-protection.sh 50从源码看add-branch-protection.sh 会依次完成以下校验与操作校验传入的发布号是正整数^[0-9]$确认仓库根目录存在.asf.yaml通过 GitHub APIhttps://api.github.com/repos/apache/datafusion/branches/branch-50校验branch-50已在官方仓库存在返回非 200 则报错退出检查.asf.yaml中是否已存在branch-50:块存在则报错避免重复添加用 awk 定位最后一个branch-XX:块在其required_approving_review_count:行后插入新块。脚本会在.asf.yaml中追加如下内容branch-50: required_pull_request_reviews: required_approving_review_count: 1之后提交变更、推送到origin/protect_branch_50、创建针对main的 PR 并合并最后在 Discord/Slack 上通知社区发布分支已创建。4. Backport 紧急变更发布分支branch-N创建、受保护且版本更新后需检查社区是否还有期望的 backport。详细流程见 docs/source/contributor-guide/release_management.md#backport-workflowbackport 工作流部分。Backport 很重要且可能出人意料因此在所有预期的 backport 应用完成后再继续后续发布步骤。从 release_management.md 可以确认其准入标准安全修复、正确性修复、稳定性与回归修复、构建/CI/测试修复以及针对已发布行为的文档修复才允许 backport新功能、破坏性 API 变更、纯重构、非正确性的性能优化与依赖升级则不建议进入发布分支。补丁版本x.y.zz ≥ 1只携带修复绝不引入新功能或破坏性变更。5. 提交更新 Changelog 的 PR每个发布版本在dev/changelog/下有自己的文件如dev/changelog/50.0.0.md应包含自上个版本以来的所有变更。仓库中该目录现存5.0.0.md到55.1.0.md的完整历史见 dev/changelog。changelog 由 Python 脚本生成需要前置条件中的 GitHub PAT 和 PyGitHub 库。先用uv安装开发依赖uv sync设置GITHUB_TOKEN环境变量后运行./dev/release/generate-changelog.py参数为两个 commit ID 或 tag后跟发布版本。例如生成50.3.0tag 到branch-51之间、面向51.0.0的 changelog[!NOTE]如果出现类似下面的错误多半是没有设置GITHUB_TOKEN环境变量Request GET ... failed with 403: rate limit exceededexport GITHUB_TOKENyour-token-here uv run ./dev/release/generate-changelog.py 50.3.0 branch-51 51.0.0 dev/changelog/51.0.0.md从 generate-changelog.py 的源码可以看到其实现机制用repo.compare(tag1, tag2)拉取两 tag 之间所有 commit再逐 commit 调用commit.get_pulls()收集关联 PR并按 PR 号去重通过正则^([a-z])(\([a-z]\))?(!)?:解析 PR 标题中的 Conventional Commits 前缀fix/feat/docs/chore等结合 GitHub 标签api change、bug、performance、enhancement、documentation将 PR 分类为 Breaking changes、Performance related、Implemented enhancements、Fixed bugs、Documentation updates、Other 六大类统计git log --prettyoneline {tag1}..{tag2} | wc -l得到 commit 数、git shortlog -sn得到贡献者数并在文末输出 Credits 贡献榜。生成后运行prettier格式化文档prettier -w dev/changelog/51.0.0.md然后提交并创建针对发布分支的 PRgit commit -a -m Update changelog6. 准备发布候选RC构件changelog 更新合并到branch-N后即可基于合并后的 commit 创建发布构件。两点注意必须具有 committer 权限才能运行这些脚本因为它们会上传到 Apache SVN 分发服务器如果 RC 之间存在代码变更在创建下一个 RC 之前应先创建并合并 changelog PR。选择 RC 编号按顺序编号rc1为 1、rc2为 2以此类推。创建 RC 的 git tag官方发布构件是签名的 tarball 和 zip 文件同时也为创建它的 commit 打 tag便于考古。正式发布 tag 形如50.3.0RC tag 形如50.3.0-rc1。例如从branch-50创建50.3.0-rc1git fetch apache git tag 50.3.0-rc1 apache/branch-50 git push apache 50.3.0-rc1务必保证 tag 格式正确Homebrew 等工具监听 tag格式错误会让用户收到不存在的版本通知。创建、签名并上传构件运行create-tarball.sh脚本参数为versiontag 和上一步确定的rc编号。例如创建50.3.0-rc1构件GITHUB_TOKENTOKEN ./dev/release/create-tarball.sh 50.3.0 1结合 create-tarball.sh 源码该脚本完成两件事创建并上传所有 RC 构件到 Apache 分发 SVN 服务器的 datafusion dev 区用git rev-list --max-count1 ${tag}解析 RC tag 对应 commit未知 tag 直接报错终止git archive ${release_hash} --prefix ${release}/ | gzip生成源码 tarball路径为dev/dist/apache-datafusion-version-rcrc/apache-datafusion-version.tar.gzgpg --armor --output ${tarball}.asc --detach-sig生成 ASCII 装甲分离签名在 tarball 所在目录用shasum -a 256/shasum -a 512生成相对路径的 checksum 文件sha256/sha512保证可直接shasum --check验证svn co --depthemptysvn addsvn ci上传到https://dist.apache.org/repos/dist/dev/datafusion。输出发送到devdatafusion.apache.org的投票邮件模板模板包含 [VOTE] 主题、RC 基于的 commit 链接、tarball 与签名地址、changelog 链接以及[ ] 1/[ ] 0/[ ] -1投票勾选项。7. 对发布候选发起投票将脚本输出的邮件发送到devdatafusion.apache.org。要在 crates.io 上发布发布必须是官方的需满足至少 3 名 PMC 成员投 1无 -1 票投票至少保持开放 72 小时给所有人审查机会。验证发布候选仓库提供 verify-release-candidate.sh 协助验证用法./dev/release/verify-release-candidate.sh 50.3.0 1从源码看该脚本的验证链条非常完整依赖自检L21-L50检查curl、git、gpg、cc、protoc是否在 PATH并确认存在shasum或sha256sum/sha512sum二者之一缺失即退出下载并导入 KEYS从 dist dev 区下载 KEYS 并gpg --import以验证签名者公钥可信签名与校验和验证L98-L121下载 tarball、.asc、.sha256、.sha512四个文件对每个*.asc执行gpg --verify再进入所在目录用shasum -a 256 -c/shasum -a 512 -c校验checksum 文件只含 basename故需进入目录执行源码分发构建测试L142-L179解压 tarball 后安装 rustup 工具链按仓库rust-toolchain.toml指定的版本执行cargo fmt --all -- --check任何格式错误即失败、克隆arrow-testing与parquet-testing测试数据仓库、cargo build、cargo test --profileci --all --featuresavro并 grep 检查所有Cargo.toml不含SNAPSHOT发布版不能带快照版本最后对datafusion/common执行cargo publish --dry-run预检发布可行性。若要求变更发布未通过或出现紧急 backport 请求从第 4 步重新开始。若投票通过宣布结果在 Datafusion dev 列表回复 RC 投票线程新主题在旧主题前加[RESULT]前缀。示例公告模板The vote has passed with NUMBER 1 votes. Thank you to all who helped with the release verification.8. 最终化发布仅 PMC 成员本节步骤在发布获批后只能由 PMC 成员执行。使用release-tarball.sh脚本将构件移动到 SVN 的 release 区例如https://dist.apache.org/repos/dist/release/datafusion/datafusion-50.3.0/./dev/release/release-tarball.sh 50.3.0 1从 release-tarball.sh 源码看脚本执行过程为校验参数数量并以read -r -p交互式确认回答必须为y否则取消重新创建临时目录svn co检出 dev 区的apache-datafusion-${version}-rc${rc}与 release 区根目录两个工作副本将 dev 构件复制到 release 工作副本的datafusion-${version}/目录并svn addsvn ci -m Apache DataFusion ${version}提交正式发布成功后清理临时目录并打印发布地址。执行成功即代表发布正式生效。9. 创建正式发布的 git tag用正式发布 tag 标记同一 RC commitgit checkout 50.3.0-rc1 git tag 50.3.0 git push apache 50.3.0这样保证 crates.io 上发布的源码与社区投票批准的 tarball 完全一致且便于代码考古。10. 发布到 crates.io只有经过批准的 tarball 发布才能推送到 crates.io以符合 ASF 治理标准。流程为按 Rust 官方发布文档创建 crates.io 账号并登录再被添加为所有 DataFusion crate 的 owner下载并解压官方发布 tarball确认 tarball 内Cargo.toml版本正确如version 50.3.0依依赖树顺序逐一cargo publish(cd datafusion/common cargo publish) (cd datafusion/common-runtime cargo publish) (cd datafusion/doc cargo publish) (cd datafusion/expr-common cargo publish) (cd datafusion/macros cargo publish) (cd datafusion/proto-common cargo publish) (cd datafusion/proto-models cargo publish) (cd datafusion/physical-expr-common cargo publish) (cd datafusion/functions-aggregate-common cargo publish) (cd datafusion/functions-window-common cargo publish) (cd datafusion/expr cargo publish) (cd datafusion/execution cargo publish) (cd datafusion/functions cargo publish) (cd datafusion/physical-expr cargo publish) (cd datafusion/functions-aggregate cargo publish) (cd datafusion/functions-window cargo publish) (cd datafusion/physical-expr-adapter cargo publish) (cd datafusion/functions-nested cargo publish) (cd datafusion/physical-plan cargo publish) (cd datafusion/session cargo publish) (cd datafusion/sql cargo publish) (cd datafusion/datasource cargo publish) (cd datafusion/optimizer cargo publish) (cd datafusion/catalog cargo publish) (cd datafusion/datasource-arrow cargo publish) (cd datafusion/datasource-avro cargo publish) (cd datafusion/datasource-csv cargo publish) (cd datafusion/datasource-json cargo publish) (cd datafusion/pruning cargo publish) (cd datafusion/datasource-parquet cargo publish) (cd datafusion/functions-table cargo publish) (cd datafusion/physical-optimizer cargo publish) (cd datafusion/catalog-listing cargo publish) (cd datafusion/core cargo publish) (cd datafusion-cli cargo publish) (cd datafusion/proto cargo publish) (cd datafusion/spark cargo publish) (cd datafusion/substrait cargo publish) (cd datafusion/ffi cargo publish) (cd datafusion/sqllogictest cargo publish)这些目录与根 Cargo.toml 中列出的 workspace 成员一一对应共 40 余个 crate从datafusion-common这类基础 crate 开始到datafusion聚合 crate 结束严格遵循 Cargo 依赖顺序。注意crates.io 发布依赖 crate 的依赖树上述列表顺序可能不完全正确。如果 crates.io 报依赖版本不匹配错误如failed to select a version for the requirement datafusion-proto ^53.1.0只需重新运行所有发布命令即可已发布成功的 crate 会跳过或幂等处理。发布 datafusion-cli 到 Homebrewdatafusionformula 会自动更新社区维护的 Homebrew core PR 机制无需额外操作。11. 同步 changelog 和版本到 main将发布分支上的版本与 changelog 变更同步回main并创建 PRgit fetch apache git checkout -b sync_change_log_versionCherry-pick 或补丁应用第 2 步的版本更新Cherry-pick 或补丁应用第 5 步的 changelog 更新提交变更git commit -a -m Sync changelog and version to main推送到origin/sync_change_log_version创建针对main的 PR 并合并这一步保证main上的版本号与 changelog 始终反映最新发布状态为下一个发布周期做好准备。12. 添加发布到 Apache Reporter发布完成后请将发布添加到 Apache Reporterreporter 系统一般会发提醒邮件错过时也可在https://reporter.apache.org/addrelease.html?datafusion手动添加参照以往发布示例。发布信息用于生成董事会报告board report模板。13. 删除旧的 RC 和旧版本遵循 ASF 的归档政策when to archive。RC 一旦发布正式版即应删除。列出 DataFusion 的发布候选svn ls https://dist.apache.org/repos/dist/dev/datafusion删除某个发布候选svn delete -m delete old DataFusion RC https://dist.apache.org/repos/dist/dev/datafusion/apache-datafusion-50.0.0-rc1/正式发布区只保留最新版本发布新版后删除旧版svn ls https://dist.apache.org/repos/dist/release/datafusionsvn delete -m delete old DataFusion release https://dist.apache.org/repos/dist/release/datafusion/datafusion-50.0.0发布脚本工具族一览与速查脚本位置作用add-branch-protection.shdev/release/add-branch-protection.sh校验发布分支存在后在.asf.yaml注入分支保护块generate-changelog.pydev/release/generate-changelog.py基于 GitHub PR 标签与 Conventional Commits 标题生成 changelogcreate-tarball.shdev/release/create-tarball.sh从 RC tag 生成签名 tarball、校验和并上传 dist/dev输出投票邮件verify-release-candidate.shdev/release/verify-release-candidate.sh下载 RC 构件验证 GPG 签名、SHA-256/512 校验和并执行完整构建测试release-tarball.shdev/release/release-tarball.sh投票通过后将构件从 dist/dev 复制到 dist/release 正式归档check-rat-report.pydev/release/check-rat-report.py结合 rat_exclude_files.txt 校验 RAT 许可证报告确保源码分发不含未授权文件create-tarball.sh生成的 tarball 是社区投票与最终发布的对象verify-release-candidate.sh提供了一键式的标准化验证路径投票邮件中也会引导社区按此流程验证check-rat-report.py则从许可证合规角度保障源码构件符合 ASF 政策对 RAT 报告的每个 resource 检查 license-approval未批准且不在排除列表的文件会打印 NOT APPROVED 并以非零码退出。各脚本内部都引用了 dev/release/README.md 作为完整发布说明本文即对其展开的逐步实现解读。总结Apache DataFusion 的发布是一套环环相扣的工程化流程发布分支 → 版本与 changelog 更新 → RC 构件签名上传 → 72 小时社区投票 → SVN 正式归档 → git 正式 tag → crates.io 依序发布 → 同步回 main → 清理旧构件。整个过程由dev/release/下的脚本自动化支撑但关键决策backport 准入、RC 是否通过、何时发布仍由社区与 PMC 通过投票与跟踪 issue 协作完成。理解这条链路无论你是想要贡献 backport 的贡献者还是承担发布任务的维护者都能在正确的环节、以正确的方式推进版本发布。赞分享大数据数据分析后端【免费下载链接】datafusionApache DataFusion SQL Query Engine项目地址https://gitcode.com/gh_mirrors/datafu/datafusion点击查看免费下载相关推荐Apache Superset 版本发布全流程指南从 RC 打包、社区投票到 PyPI/Docker/npm 发布Apache Superset 版本发布全流程指南从 RC 打包、社区投票到 PyPI/Docker/npm 发布 Apache Superset 采用 Ap数据可视化数据分析后端Apache DolphinScheduler 版本发布全流程指南GPG 签名、Maven 发布、SVN 上传与社区投票Apache DolphinScheduler 版本发布全流程指南GPG 签名、Maven 发布、SVN 上传与社区投票 Apache DolphinSche任务调度大数据后端前端Apache Iceberg 完整发布流程指南从 RC 候选构建、社区投票到版本化文档与候选版本验证Apache Iceberg 完整发布流程指南从 RC 候选构建、社区投票到版本化文档与候选版本验证 Apache Iceberg 作为 Apache 顶级项数据湖大数据数据存储上一篇MemCells技术解密EverMemOS原子化记忆单元设计原理下一篇RedditOS网络层实现原理OAuth认证与API集成完全教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考