Apache Arrow R 包 CRAN 打包全流程基于 r/PACKAGING.md 的发布检查单深度解析【免费下载链接】arrowApache Arrow is the universal columnar format and multi-language toolbox for fast data interchange and in-memory analytics项目地址: https://gitcode.com/GitHub_Trending/arrow3/arrowApache Arrow 的 R 接口包r/目录每年需多次提交至 CRAN其打包流程横跨版本标签、分支策略、预编译二进制校验、多平台构建验证与文档站点更新等多个环节。本文以 r/PACKAGING.md 这份《CRAN 发布打包检查单》为核心骨架结合仓库中的自动化构建脚本r/Makefile、校验和下载工具r/tools/update-checksums.R、贡献者统计脚本r/tools/contributor_stats.R以及配套的 Claude Code 技能文件.claude/skills/r-cran-release/SKILL.md完整梳理一次 CRAN 发布从 RC 之前到 CRAN 托管二进制上线的全链路操作帮助读者掌握 R 包发布检查单中每一项背后的实际机制与可复制命令。一、为什么 R 包需要一份独立的打包检查单Apache Arrow 是多语言项目同一版本标签同时驱动 C、Python、R、Rust 等多个语言的发布。R 包有其特殊的发布形态r/DESCRIPTION 显示包版本为25.0.1.9000要求R ( 4.2)SystemRequirements需要 C20且cmake 3.26仅在全源码构建时需要Linux 上 AWS S3 支持还需 libcurl、opensslAzure 需 libxml2Biarch: true表明包同时提供双架构二进制。R 包默认不携带完整 C 源码构建而是依赖从 ASF artifactory 下载的预编译 libarrow 二进制见下文校验和机制源码构建只是兜底路径。R 包存在两类发布节奏跟随 Arrow C 主版本发布的“配套版本”以及仅修复 R 侧问题的CRAN-only / patch release检查单末尾明确标注了 “patch releases only” 与 “CRAN-only releases” 两类专属步骤。r/PACKAGING.md 开篇还指出本检查单同时以 Claude Code 技能的形式存放在 SKILL.md其中把同样的步骤拆分为 25 个带确认点的子步骤并额外约束“技能自身绝不执行git push所有推送命令必须交由用户手动确认执行”“每完成一步需回写 tracking issue 的 checkbox”。这意味着检查单本身也是被自动化流程消费的“单一事实来源”——SKILL.md 第 1 步直接通过gh issue create读取r/PACKAGING.md中所有- [ ]开头的清单行作为 issue 正文。二、发布前RC 创建之前状态盘点与物料准备检查单的第一阶段标题为 “Before the Arrow Release Candidate Is Created”共 7 项全部完成后方可等待 RC创建 GitHub tracking issue标题格式为[R] CRAN packaging checklist for version X.Y.Z正文直接复制本检查单。SKILL.md 给出了可直接执行的命令gh issue create 用sed -n /^- \[ \]/,$p抽取清单行并强调要记录 issue 编号、随进度勾选 checkbox。复审弃用函数把需要推进弃用状态deprecation → defunct/removed的函数处理掉。SKILL.md 第 4 步给出定位命令grep -rn \.Deprecated r/R/*.R逐项判断是改为.Defunct()还是直接删除。评估 nightly 测试与 nightly 打包构建状态检查单特别说明这些 nightly 检查“复制了 CRAN 运行的绝大多数检查”因此必须全部通过或至少理解失败是否未必会导致 CRAN 拒收。SKILL.md 对应第 5 步建议通过 Zulip 或 crossbow 面板查看。检查当前 CRAN check 结果查看 CRAN 官方的 arrow 检查结果页全部平台应为 OK 或 NOTE。SKILL.md 第 6 步补充了一条关键判定标准因内嵌 Arrow C 导致的包体积 NOTE如 “installed size is 130 Mb”属预期情况可忽略其他 NOTE 或任何 ERROR/WARN 都必须调查。确保 README 内容准确且最新。在 RC 提交上运行urlchecker::url_check()针对 R 目录。检查单特别提示徽章badges相关的 URL 报错可以忽略因为 CRAN 发布分支会删除徽章——徽章 URL 在 CRAN 环境下并不合适。打磨 NEWS 但不更新版本号版本号由后续流程自动处理。定位本周期 R 侧提交的标准命令是git log --oneline sha of last release..HEAD | grep \[R\]打磨遵循 tidyverse 的 NEWS 风格规范。仓库中的 r/NEWS.md 展示了该风格的实际形态每个版本小节按Breaking changes/New features/Minor improvements and fixes/Installation分类条目使用现在时并附带 issue 编号与贡献者署名例如# arrow 25.0.1 ## Minor improvements and fixes - Improved mimalloc memory allocator configuration on macOS (#50428).检查单最后还要求主版本major release需提前准备突出新特性的社媒内容。以上步骤完成后检查单以一句 “Wait for the release candidate to be created” 作为阶段分界。三、RC 创建后与投票通过维护分支策略RC 创建后的第一步只有一条从 RC 提交创建 CRAN 发布分支命名maint-X.Y.Z-r并推送到 upstream。SKILL.md 第 2 步对此做了重要细化值得特别关注其决策逻辑先git fetch upstream --tags然后git tag -l apache-arrow-X.Y.Z*检查最终 tag 是否已存在若apache-arrow-X.Y.Z无 rc 后缀已存在说明投票已通过必须从最终 tag 拉分支——不能询问使用哪个 RC因为早期 RC 与最终 tag 可能是不同提交仅当最终 tag 尚不存在投票进行中时才询问用户采用哪个 RC如 rc1、rc2从apache-arrow-X.Y.Z-rcN拉分支分支创建后git push upstream maint-X.Y.Z-r且此后所有操作都在该分支上进行。随后进入 “Wait for Arrow Release Vote” 阶段唯一动作是确认发布投票通过若按上述规则从最终 tag 拉了分支此步自动视为完成。四、生成待提交的 R 包cherry-pick、校验和与make build“Generate R Package to Submit to CRAN” 阶段是整个流程中命令密度最高的部分按顺序包含 5 项检查单条目若 RC 提交有更新将 CRAN 发布分支 rebase 到该提交挑选 main 上 RC 之后出现的、用于修复 CRAN 提交问题的提交cherry-pick 进maint-X.Y.Z-r。SKILL.md 第 10 步给出取 merge commit 的完整方法gh pr view PR --repo apache/arrow --json mergeCommit,title --jq {sha: .mergeCommit.oid, title: .title}逐个git cherry-pick sha从 r/README.md 中移除徽章。SKILL.md 第 3 步给出精确操作删除!-- badges: start --与!-- badges: end --之间的全部内容含两端标记行再次运行urlchecker::url_check()——此时徽章已删所有 URL 应通过创建验证 PR标题WIP: [R] Verify CRAN release-X.Y.Z-rcX并在 PR 中评论github-actions crossbow submit --group r用 R 组的 crossbow 任务对这条 CRAN 专属分支跑全量 R 作业SKILL.md 要求进入 CRAN 提交前必须确认全部 crossbow 作业通过。4.1 更新 libarrow 二进制校验和检查单中的两条命令对应仓库内的 r/tools/update-checksums.RRscript tools/update-checksums.R libarrow version git add -f tools/checksums/ git commit -m [CRAN] Add checksums从源码看该脚本的工作机制脚本头部注释明确必须在投票通过、产物移入最终目录之后运行它会把校验和文件下载到tools/checksums/目录布局镜像 artifactory安装包时 R 端的*libs.R用这些文件验证下载的预编译二进制它从 dev/tasks/tasks.yml 中抽取所有r-libarrow-...zip二进制路径当前包括r-libarrow-windows-x86_64、r-libarrow-linux-x86_64、r-libarrow-linux-arm64、r-libarrow-darwin-arm64、r-libarrow-darwin-x86_64五个平台变体把{no_rc_r_version}占位符替换为传入的 libarrow 版本再为每个路径追加.sha512后缀下载对 Windows 平台的校验和文件会用sedmacOS 上用gsed去除\r因为 UNIX 换行符会导致 msys2 的sha512sum报错脚本自带防护必须从r/目录运行通过检查../dev/tasks/tasks.yml是否存在验证且严格校验参数个数。校验和文件被-f强制git add是因为tools/checksums/目录平时被 gitignore仅在发布分支上落盘这正是 “CRAN 专属分支” 与 main 分支的又一处差异。4.2 重新构建 tarballmake build到底做了什么检查单最后一条要求重新生成arrow_X.Y.Z.tar.gz即make build并解释该目标会 “清理旧产物、重新生成文档、同步 C 文件、构建包”同时提醒因为该过程会安装包必须确保 configure 脚本可获取的 Arrow C 版本与 R 包内置vendored的版本一致必要时需要unset ARROW_HOME。对照 r/Makefile 可以逐项印证build: $(MAKE) clean $(MAKE) doc $(MAKE) sync-cpp R CMD build ${args} .clean删除src/*.o、src/*.so、src/Makevars、tools/cpp/等全部构建中间物doc先跑pre-commit风格检查再执行data-raw/docgen.R与roxygen2::roxygenize()重新生成.Rd文档sync-cpp把仓库根的../cpp用 rsync 同步进tools/cpp/排除测试、examples、gandiva、JNI、子模块等并把根目录的.env复制为tools/dotenv、NOTICE.txt/LICENSE.txt拷入tools/因为 “tools 下的文件在构建期可用但运行期不可用”且 thirdparty cmake 期望在cpp/上一级找到.env/NOTICE.txt/LICENSE.txt最后R CMD build产出 tarball。SKILL.md 第 12/15 步进一步补充了构建前后的细节构建前先确认git branch --show-current是maint-X.Y.Z-r且工作区干净git clean -f -d用echo ARROW_HOME${ARROW_HOME:-not set}检查并必要时unset ARROW_HOME构建后git status检查是否有新生成的.Rd文档变更有则以 “[R] Update generated documentation” 提交最终用devtools::check_built(arrow_VERSION.tar.gz)本地做一次完整 check。Makefile 中另有check/release目标直接执行R CMD check --as-cran是本地模拟 CRAN 检查的快捷方式。五、验证 R 包专属的二进制 Arrow C 发行版检查单设有独立小节 “Check Binary Arrow C Distributions Specific to the R Package”共 4 项覆盖 R 包在三大平台上“走预编译二进制而非源码编译”的关键路径平台验证动作Windows将.tar.gz上传至 win-builder仅 r-devel与包维护者 Jon 确认 check 干净结果会自动邮件通知他macOS上传至 macOS Builder 并确认 check 干净Ubuntu执行install.packages(arrow_X.Y.Z.tar.gz)确认安装时使用了托管的预编译二进制而非源码编译本地最后再跑一次devtools::check_built(arrow_X.Y.Z.tar.gz)检查单原文备注 “for luck”这一步与第四节校验和机制首尾呼应update-checksums.R下载的.sha512文件保证安装期二进制完整性而本节的人工验证则确保五个平台变体的二进制对应 tasks.yml 中列出的 windows-x86_64、linux-x86_64、linux-arm64、darwin-arm64、darwin-x86_64在真实安装场景中都能被正确命中。六、提交 CRAN 与接受后的收尾工作6.1 提交仅维护者可执行检查单强调 “This step must be done by the current package maintainer”动作只有两条将arrow_X.Y.Z.tar.gz上传到 CRAN 官方提交页面当前为奥地利 WU 的 cransubmit 节点随后确认收到的提交邮件。6.2 CRAN 接受后的 9 项收尾打 r-universe 标签对 CRAN 分支顶点强制打r-universe-release标签并推送 upstreamgit tag -f r-universe-release maint-X.Y.Z-r git push upstream r-universe-release --force更新向后兼容矩阵在 dev/tasks/r/github.linux.arrow.version.back.compat.yml 的 matrix 中新增一行。从源码结构看该任务分两阶段write-filesjob 用当前 main 代码在 ubuntu 上安装 R 包并写出 parquet 制品read-filesjob 则按 matrix 中的历史版本逐一remotes::install_version(arrow, old_arrow_version)用旧版本 R 包读取新写出的文件。当前 matrix 从6.0.1一路排到24.0.0并记录了每个旧版本当年对应的 R 版本如 24.0.0 配 R 4.6、19.0.1 配 R 4.4保证 “用本次 R 包写入、用旧 R 包读回” 的长期可读性——每个新 CRAN 版本被接受后正是往这张表里追加一行。仅 patch release同步更新三处版本号ci/scripts/PKGBUILD、r/DESCRIPTION、r/NEWS.md。仅 CRAN-only release用pkgdown::build_news()重建 news 页并向文档站点的asf-site分支提 PR以arrow/r/docs/news/index.html替换站点中对应的docs/r/news/index.html同时把 r/pkgdown/assets/versions.json 中的版本号同步 bump 并更新到文档站。复审并更新本检查单模板打包流程自身也是持续演进的活文档。等待 CRAN 托管二进制在 CRAN 的 arrow 包页面体现新版本。发布社媒内容使用 r/tools/contributor_stats.R 中的release_contributor_stats()计算贡献者数据。从源码看该函数在两个 release tag 之间统计总贡献者数、仅 C 贡献者、仅 R 贡献者、两者皆有者以及首次贡献者first_timers与first_timers_r分别按全仓库与r子目录计算例如在仓库根运行source(r/tools/contributor_stats.R) release_contributor_stats(apache-arrow-20.0.0, apache-arrow-21.0.0)脚本内部通过git log --prettyformat:%an range -- dir取作者并做集合差/交运算且对非法 ref 有明确的报错提示。检查本次 C 侧更新为需要 R 绑定的新 C 能力创建 issue。SKILL.md 第 24 步给出定位命令git log --oneline apache-arrow-PREV..apache-arrow-VER -- cpp/ | head -50。七、可复用的要点总结分支即契约maint-X.Y.Z-r分支承载了全部 CRAN 专属变更删徽章、cherry-pick、tools/checksums/下的强制追踪文件、重新生成的文档与 main 分支保持隔离能基于最终 tag 就不要基于 RC。双重检查保险nightly 打包构建与 crossbow 的 R 组作业github-actions crossbow submit --group r在提交前模拟 CRAN 检查win-builder/macOS Builder/Ubuntu 安装验证在提交后确认二进制路径devtools::check_built作为最后一道本地防线。命令都以仓库内脚本为锚make build的 clean/doc/sync-cpp 三步对应 r/Makefile 中明确定义的目标校验和下载、贡献者统计、向后兼容矩阵等均有对应仓库文件可查证检查单中每一条都能在源码或 CI 任务中找到落点这也是该检查单可直接被 SKILL.md 这类自动化技能逐步执行的依据。【免费下载链接】arrowApache Arrow is the universal columnar format and multi-language toolbox for fast data interchange and in-memory analytics项目地址: https://gitcode.com/GitHub_Trending/arrow3/arrow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache Arrow R 包 CRAN 打包全流程：基于 r/PACKAGING.md 的发布检查单深度解析
Apache Arrow R 包 CRAN 打包全流程基于 r/PACKAGING.md 的发布检查单深度解析【免费下载链接】arrowApache Arrow is the universal columnar format and multi-language toolbox for fast data interchange and in-memory analytics项目地址: https://gitcode.com/GitHub_Trending/arrow3/arrowApache Arrow 的 R 接口包r/目录每年需多次提交至 CRAN其打包流程横跨版本标签、分支策略、预编译二进制校验、多平台构建验证与文档站点更新等多个环节。本文以 r/PACKAGING.md 这份《CRAN 发布打包检查单》为核心骨架结合仓库中的自动化构建脚本r/Makefile、校验和下载工具r/tools/update-checksums.R、贡献者统计脚本r/tools/contributor_stats.R以及配套的 Claude Code 技能文件.claude/skills/r-cran-release/SKILL.md完整梳理一次 CRAN 发布从 RC 之前到 CRAN 托管二进制上线的全链路操作帮助读者掌握 R 包发布检查单中每一项背后的实际机制与可复制命令。一、为什么 R 包需要一份独立的打包检查单Apache Arrow 是多语言项目同一版本标签同时驱动 C、Python、R、Rust 等多个语言的发布。R 包有其特殊的发布形态r/DESCRIPTION 显示包版本为25.0.1.9000要求R ( 4.2)SystemRequirements需要 C20且cmake 3.26仅在全源码构建时需要Linux 上 AWS S3 支持还需 libcurl、opensslAzure 需 libxml2Biarch: true表明包同时提供双架构二进制。R 包默认不携带完整 C 源码构建而是依赖从 ASF artifactory 下载的预编译 libarrow 二进制见下文校验和机制源码构建只是兜底路径。R 包存在两类发布节奏跟随 Arrow C 主版本发布的“配套版本”以及仅修复 R 侧问题的CRAN-only / patch release检查单末尾明确标注了 “patch releases only” 与 “CRAN-only releases” 两类专属步骤。r/PACKAGING.md 开篇还指出本检查单同时以 Claude Code 技能的形式存放在 SKILL.md其中把同样的步骤拆分为 25 个带确认点的子步骤并额外约束“技能自身绝不执行git push所有推送命令必须交由用户手动确认执行”“每完成一步需回写 tracking issue 的 checkbox”。这意味着检查单本身也是被自动化流程消费的“单一事实来源”——SKILL.md 第 1 步直接通过gh issue create读取r/PACKAGING.md中所有- [ ]开头的清单行作为 issue 正文。二、发布前RC 创建之前状态盘点与物料准备检查单的第一阶段标题为 “Before the Arrow Release Candidate Is Created”共 7 项全部完成后方可等待 RC创建 GitHub tracking issue标题格式为[R] CRAN packaging checklist for version X.Y.Z正文直接复制本检查单。SKILL.md 给出了可直接执行的命令gh issue create 用sed -n /^- \[ \]/,$p抽取清单行并强调要记录 issue 编号、随进度勾选 checkbox。复审弃用函数把需要推进弃用状态deprecation → defunct/removed的函数处理掉。SKILL.md 第 4 步给出定位命令grep -rn \.Deprecated r/R/*.R逐项判断是改为.Defunct()还是直接删除。评估 nightly 测试与 nightly 打包构建状态检查单特别说明这些 nightly 检查“复制了 CRAN 运行的绝大多数检查”因此必须全部通过或至少理解失败是否未必会导致 CRAN 拒收。SKILL.md 对应第 5 步建议通过 Zulip 或 crossbow 面板查看。检查当前 CRAN check 结果查看 CRAN 官方的 arrow 检查结果页全部平台应为 OK 或 NOTE。SKILL.md 第 6 步补充了一条关键判定标准因内嵌 Arrow C 导致的包体积 NOTE如 “installed size is 130 Mb”属预期情况可忽略其他 NOTE 或任何 ERROR/WARN 都必须调查。确保 README 内容准确且最新。在 RC 提交上运行urlchecker::url_check()针对 R 目录。检查单特别提示徽章badges相关的 URL 报错可以忽略因为 CRAN 发布分支会删除徽章——徽章 URL 在 CRAN 环境下并不合适。打磨 NEWS 但不更新版本号版本号由后续流程自动处理。定位本周期 R 侧提交的标准命令是git log --oneline sha of last release..HEAD | grep \[R\]打磨遵循 tidyverse 的 NEWS 风格规范。仓库中的 r/NEWS.md 展示了该风格的实际形态每个版本小节按Breaking changes/New features/Minor improvements and fixes/Installation分类条目使用现在时并附带 issue 编号与贡献者署名例如# arrow 25.0.1 ## Minor improvements and fixes - Improved mimalloc memory allocator configuration on macOS (#50428).检查单最后还要求主版本major release需提前准备突出新特性的社媒内容。以上步骤完成后检查单以一句 “Wait for the release candidate to be created” 作为阶段分界。三、RC 创建后与投票通过维护分支策略RC 创建后的第一步只有一条从 RC 提交创建 CRAN 发布分支命名maint-X.Y.Z-r并推送到 upstream。SKILL.md 第 2 步对此做了重要细化值得特别关注其决策逻辑先git fetch upstream --tags然后git tag -l apache-arrow-X.Y.Z*检查最终 tag 是否已存在若apache-arrow-X.Y.Z无 rc 后缀已存在说明投票已通过必须从最终 tag 拉分支——不能询问使用哪个 RC因为早期 RC 与最终 tag 可能是不同提交仅当最终 tag 尚不存在投票进行中时才询问用户采用哪个 RC如 rc1、rc2从apache-arrow-X.Y.Z-rcN拉分支分支创建后git push upstream maint-X.Y.Z-r且此后所有操作都在该分支上进行。随后进入 “Wait for Arrow Release Vote” 阶段唯一动作是确认发布投票通过若按上述规则从最终 tag 拉了分支此步自动视为完成。四、生成待提交的 R 包cherry-pick、校验和与make build“Generate R Package to Submit to CRAN” 阶段是整个流程中命令密度最高的部分按顺序包含 5 项检查单条目若 RC 提交有更新将 CRAN 发布分支 rebase 到该提交挑选 main 上 RC 之后出现的、用于修复 CRAN 提交问题的提交cherry-pick 进maint-X.Y.Z-r。SKILL.md 第 10 步给出取 merge commit 的完整方法gh pr view PR --repo apache/arrow --json mergeCommit,title --jq {sha: .mergeCommit.oid, title: .title}逐个git cherry-pick sha从 r/README.md 中移除徽章。SKILL.md 第 3 步给出精确操作删除!-- badges: start --与!-- badges: end --之间的全部内容含两端标记行再次运行urlchecker::url_check()——此时徽章已删所有 URL 应通过创建验证 PR标题WIP: [R] Verify CRAN release-X.Y.Z-rcX并在 PR 中评论github-actions crossbow submit --group r用 R 组的 crossbow 任务对这条 CRAN 专属分支跑全量 R 作业SKILL.md 要求进入 CRAN 提交前必须确认全部 crossbow 作业通过。4.1 更新 libarrow 二进制校验和检查单中的两条命令对应仓库内的 r/tools/update-checksums.RRscript tools/update-checksums.R libarrow version git add -f tools/checksums/ git commit -m [CRAN] Add checksums从源码看该脚本的工作机制脚本头部注释明确必须在投票通过、产物移入最终目录之后运行它会把校验和文件下载到tools/checksums/目录布局镜像 artifactory安装包时 R 端的*libs.R用这些文件验证下载的预编译二进制它从 dev/tasks/tasks.yml 中抽取所有r-libarrow-...zip二进制路径当前包括r-libarrow-windows-x86_64、r-libarrow-linux-x86_64、r-libarrow-linux-arm64、r-libarrow-darwin-arm64、r-libarrow-darwin-x86_64五个平台变体把{no_rc_r_version}占位符替换为传入的 libarrow 版本再为每个路径追加.sha512后缀下载对 Windows 平台的校验和文件会用sedmacOS 上用gsed去除\r因为 UNIX 换行符会导致 msys2 的sha512sum报错脚本自带防护必须从r/目录运行通过检查../dev/tasks/tasks.yml是否存在验证且严格校验参数个数。校验和文件被-f强制git add是因为tools/checksums/目录平时被 gitignore仅在发布分支上落盘这正是 “CRAN 专属分支” 与 main 分支的又一处差异。4.2 重新构建 tarballmake build到底做了什么检查单最后一条要求重新生成arrow_X.Y.Z.tar.gz即make build并解释该目标会 “清理旧产物、重新生成文档、同步 C 文件、构建包”同时提醒因为该过程会安装包必须确保 configure 脚本可获取的 Arrow C 版本与 R 包内置vendored的版本一致必要时需要unset ARROW_HOME。对照 r/Makefile 可以逐项印证build: $(MAKE) clean $(MAKE) doc $(MAKE) sync-cpp R CMD build ${args} .clean删除src/*.o、src/*.so、src/Makevars、tools/cpp/等全部构建中间物doc先跑pre-commit风格检查再执行data-raw/docgen.R与roxygen2::roxygenize()重新生成.Rd文档sync-cpp把仓库根的../cpp用 rsync 同步进tools/cpp/排除测试、examples、gandiva、JNI、子模块等并把根目录的.env复制为tools/dotenv、NOTICE.txt/LICENSE.txt拷入tools/因为 “tools 下的文件在构建期可用但运行期不可用”且 thirdparty cmake 期望在cpp/上一级找到.env/NOTICE.txt/LICENSE.txt最后R CMD build产出 tarball。SKILL.md 第 12/15 步进一步补充了构建前后的细节构建前先确认git branch --show-current是maint-X.Y.Z-r且工作区干净git clean -f -d用echo ARROW_HOME${ARROW_HOME:-not set}检查并必要时unset ARROW_HOME构建后git status检查是否有新生成的.Rd文档变更有则以 “[R] Update generated documentation” 提交最终用devtools::check_built(arrow_VERSION.tar.gz)本地做一次完整 check。Makefile 中另有check/release目标直接执行R CMD check --as-cran是本地模拟 CRAN 检查的快捷方式。五、验证 R 包专属的二进制 Arrow C 发行版检查单设有独立小节 “Check Binary Arrow C Distributions Specific to the R Package”共 4 项覆盖 R 包在三大平台上“走预编译二进制而非源码编译”的关键路径平台验证动作Windows将.tar.gz上传至 win-builder仅 r-devel与包维护者 Jon 确认 check 干净结果会自动邮件通知他macOS上传至 macOS Builder 并确认 check 干净Ubuntu执行install.packages(arrow_X.Y.Z.tar.gz)确认安装时使用了托管的预编译二进制而非源码编译本地最后再跑一次devtools::check_built(arrow_X.Y.Z.tar.gz)检查单原文备注 “for luck”这一步与第四节校验和机制首尾呼应update-checksums.R下载的.sha512文件保证安装期二进制完整性而本节的人工验证则确保五个平台变体的二进制对应 tasks.yml 中列出的 windows-x86_64、linux-x86_64、linux-arm64、darwin-arm64、darwin-x86_64在真实安装场景中都能被正确命中。六、提交 CRAN 与接受后的收尾工作6.1 提交仅维护者可执行检查单强调 “This step must be done by the current package maintainer”动作只有两条将arrow_X.Y.Z.tar.gz上传到 CRAN 官方提交页面当前为奥地利 WU 的 cransubmit 节点随后确认收到的提交邮件。6.2 CRAN 接受后的 9 项收尾打 r-universe 标签对 CRAN 分支顶点强制打r-universe-release标签并推送 upstreamgit tag -f r-universe-release maint-X.Y.Z-r git push upstream r-universe-release --force更新向后兼容矩阵在 dev/tasks/r/github.linux.arrow.version.back.compat.yml 的 matrix 中新增一行。从源码结构看该任务分两阶段write-filesjob 用当前 main 代码在 ubuntu 上安装 R 包并写出 parquet 制品read-filesjob 则按 matrix 中的历史版本逐一remotes::install_version(arrow, old_arrow_version)用旧版本 R 包读取新写出的文件。当前 matrix 从6.0.1一路排到24.0.0并记录了每个旧版本当年对应的 R 版本如 24.0.0 配 R 4.6、19.0.1 配 R 4.4保证 “用本次 R 包写入、用旧 R 包读回” 的长期可读性——每个新 CRAN 版本被接受后正是往这张表里追加一行。仅 patch release同步更新三处版本号ci/scripts/PKGBUILD、r/DESCRIPTION、r/NEWS.md。仅 CRAN-only release用pkgdown::build_news()重建 news 页并向文档站点的asf-site分支提 PR以arrow/r/docs/news/index.html替换站点中对应的docs/r/news/index.html同时把 r/pkgdown/assets/versions.json 中的版本号同步 bump 并更新到文档站。复审并更新本检查单模板打包流程自身也是持续演进的活文档。等待 CRAN 托管二进制在 CRAN 的 arrow 包页面体现新版本。发布社媒内容使用 r/tools/contributor_stats.R 中的release_contributor_stats()计算贡献者数据。从源码看该函数在两个 release tag 之间统计总贡献者数、仅 C 贡献者、仅 R 贡献者、两者皆有者以及首次贡献者first_timers与first_timers_r分别按全仓库与r子目录计算例如在仓库根运行source(r/tools/contributor_stats.R) release_contributor_stats(apache-arrow-20.0.0, apache-arrow-21.0.0)脚本内部通过git log --prettyformat:%an range -- dir取作者并做集合差/交运算且对非法 ref 有明确的报错提示。检查本次 C 侧更新为需要 R 绑定的新 C 能力创建 issue。SKILL.md 第 24 步给出定位命令git log --oneline apache-arrow-PREV..apache-arrow-VER -- cpp/ | head -50。七、可复用的要点总结分支即契约maint-X.Y.Z-r分支承载了全部 CRAN 专属变更删徽章、cherry-pick、tools/checksums/下的强制追踪文件、重新生成的文档与 main 分支保持隔离能基于最终 tag 就不要基于 RC。双重检查保险nightly 打包构建与 crossbow 的 R 组作业github-actions crossbow submit --group r在提交前模拟 CRAN 检查win-builder/macOS Builder/Ubuntu 安装验证在提交后确认二进制路径devtools::check_built作为最后一道本地防线。命令都以仓库内脚本为锚make build的 clean/doc/sync-cpp 三步对应 r/Makefile 中明确定义的目标校验和下载、贡献者统计、向后兼容矩阵等均有对应仓库文件可查证检查单中每一条都能在源码或 CI 任务中找到落点这也是该检查单可直接被 SKILL.md 这类自动化技能逐步执行的依据。【免费下载链接】arrowApache Arrow is the universal columnar format and multi-language toolbox for fast data interchange and in-memory analytics项目地址: https://gitcode.com/GitHub_Trending/arrow3/arrow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考