科学计算数据分析【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址https://gitcode.com/gh_mirrors/nu/numpy点击查看免费下载导读本文基于 doc/source/dev/releasing.rst 梳理 NumPy 官方完整的版本发布流程。该索引文档通过.. include::引入了三份核心操作手册——doc/HOWTO_RELEASE.rst总体发布指南、doc/RELEASE_WALKTHROUGH.rst以 2.4.0 为实例的逐步发布演练与 doc/BRANCH_WALKTHROUGH.rst分支创建演练。读完本文你将掌握 NumPy 从创建 maintenance 分支、检查 C API 版本、生成 changelog 与 release notes到构建/上传 wheel、发布到 PyPI 与 GitHub Releases、部署文档并对外公告的完整发布链路以及每个环节对应的仓库文件与命令。一、发布前的总体准备与平台支持1.1 构建与发布信息NumPy 构建二进制发行版所需的信息主要来自三份文档即本索引所引用的三份文件doc/HOWTO_RELEASE.rst——发布总体说明覆盖平台支持、工具链、OpenBLAS、文档构建与 PyPI 上传doc/RELEASE_WALKTHROUGH.rst——以 NumPy 2.4.0 在 Linux 上的发布为实例的逐步操作演练doc/BRANCH_WALKTHROUGH.rst——以 NumPy 2.3.x 分支为实例的维护分支创建演练。另外从源码构建的详细说明见文档目录的 building 相关章节doc/source/building/。1.2 支持的平台与版本Python 版本策略NEP 29规定了最低支持哪些 Python 版本。实际发布时为了避免给其他项目带来麻烦NumPy 通常会在该最低要求的基础上再延长一段时间支持某个 Python 版本具体由发布经理release manager酌情决定。macOS目标支持与 Python.org 和cibuildwheel对给定 Python 版本所支持的范围一致的 macOS 版本。构建的 macOS wheel 兼容常见 Python 安装方式python.org 官方安装包、python-build-standaloneuv安装所用、系统 Python、conda-forge、Homebrew 和 MacPorts。Windows同时构建 32 位和 64 位 wheel支持 Windows 7、8、10。截至 2025 年 8 月x86/x86-64 使用 MSVCarm64 使用 Clang-cl构建基于cibuildwheel和 GitHub Actions。Linux在 PyPI 上发布面向 x86-64 与 aarch64 的manylinux和musllinuxwheel目前不提供 32 位平台 wheel目标支持最低的非 EOLEnd-of-Life版本并大致与cibuildwheel的节奏同步升级。BSD / Solaris / AIXPyPI 上不提供二进制 wheel但从源码构建在这些平台上可以正常工作。1.3 工具链构建 wheel 使用的工具链Linux使用manylinux/musllinuxDocker 镜像中的默认编译器通常是较新的 GCCmacOS使用 GitHub Actions runner 镜像上安装的 Apple Clang 与 XCodeWindowsx86 与 x86-64 使用 GitHub Actions runner 镜像上安装的默认 MSVC / Visual Studio 工具链。历史上为规避静态libnpymath库对 SciPy 造成的问题有时需要使用较旧工具链——如需确定确切版本号请检查numpy/numpy-release仓库代码和 CI 日志。从源码构建时的最低编译器版本要求记录在仓库根目录的meson.build文件中NumPy 2.x 已全面迁移到 Meson 构建系统。1.4 OpenBLAS、文档构建与 PyPI 上传OpenBLAS大多数 wheel 链接到由 openblas-libs 仓库提供的 OpenBLAS 版本。共享库或 DLL被打包进 wheel并重命名以避免与文件系统中其他 OpenBLAS 共享对象发生名称冲突。构建文档不再构建 PDF 文件构建 HTML 文档的要求与日常开发相同。具体逐步操作见doc/RELEASE_WALKTHROUGH.rst。上传 PyPI在 PyPI 上创建 release、上传 wheel 与 sdist 的流程已由 CI 自动化使用 PyPI 的 trusted publishing可信发布机制。详见numpy/numpy-release仓库 README 与doc/RELEASE_WALKTHROUGH.rst。生成作者/PR 列表需要一个 GitHub personal access token以便脚本访问 NumPy GitHub 仓库。有了 token 后可通过spin changelog生成作者/PR 变更日志该命令可能额外需要gitpython、pygithub等包。1.5 发布的内容物PyPI发布多个平台的 wheel 和一个 sdist源码包GitHub Releases发布与 PyPI 相同的 sdist因为 GitHub 自动生成的源码归档不完整以及 release notes 和 changelog。二、总体发布流程HOWTO_RELEASE2.1 确定发布日程典型的 feature release 节奏是两个发布候选RC加一个正式版。发布时间最好先在邮件列表上讨论以便大家及时合入各自的提交。日期确定后创建新的maintenance/x.y.z分支在 main 分支上为新版本添加空的 release notes更新 issue 跟踪器上的 Milestones。2.2 检查废弃项Deprecations在创建 release 分支之前应检查所有应移除的已废弃代码是否确实被移除所有新增的废弃项是否在 docstring 或 DeprecationWarning 中明确说明了移除版本。2.3 检查 C API 版本号C API 版本需要在三处同步维护文件作用numpy/_core/meson.build定义C_API_VERSION与C_ABI_VERSIONnumpy/_core/code_generators/cversions.txt记录各 API 版本对应的 hashnumpy/_core/include/numpy/numpyconfig.h定义NPY_X_Y_API_VERSION宏具体分三步第一步判断 API 是否变化。只有当前 API 编译出的代码能向后兼容上一发布版本才认为 API 未变。任何对 C 结构的修改或对公共接口的增补都会使 API 不再向后兼容此时需要递增numpy/_core/meson.build中的C_API_VERSION。当前仓库中该值为0x00000016对应 NumPy 2.5/2.6 系列。第二步更新 cversions.txt。如果第一步的C_API_VERSION变了或者 API 的 hash 变了就需要更新 numpy/_core/code_generators/cversions.txt。校验 hash 的方法是运行 numpy/_core/cversions.py它会调用code_generators/genapi.fullapi_hash(full_api)打印当前 API hashpython numpy/_core/cversions.py将该 hash 与cversions.txt最后一条记录比对若不同则 hash 已变化。此时需要结合合适的C_API_VERSION与 hash 在cversions.txt中新增一条记录如果 API 版本未变但 hash 变了则需要注释掉该 API 版本对应的上一条记录。典型例子是 NumPy 1.9 添加了注解hash 变了但 API 与 1.8 相同。注意 hash 只是 API 变化的校验手段并非决定性依据。如果第 1、2 步都做对了编译 release 时不应出现 API mismatch detect at the beginning of the build 警告。当前 cversions.txt 中记录了从 0x00000001 到 0x00000016NumPy 2.5.0 引入 opaque PyObject ABI 支持与NPY_DT_legacy_descriptor_proto支持NumPy 2.6.0 无变化的完整历史可作为格式参考。第三步更新 numpyconfig.h。在 numpy/_core/include/numpy/numpyconfig.h 中新增NPY_X_Y_API_VERSION宏X、Y 为 release 的主次版本号。宏的值只在 include 文件中有函数或宏被废弃时才需要比上一版本增加。例如当前文件中的系列NPY_2_3_API_VERSION 0x00000014、NPY_2_4_API_VERSION 0x00000015、NPY_2_5_API_VERSION 0x00000016、NPY_2_6_API_VERSION 0x000000162.6 未变化故值相同。另外numpy/_core/meson.build 中的C_ABI_VERSION当前为0x02000000只应在 major release 时更新——这与C_API_VERSION不同二进制兼容被打破时两者都要递增而仅 API 增加但保持二进制兼容时只递增C_API_VERSION。构建时该值会写入NPY_ABI_VERSION/NPY_API_VERSION宏。2.4 检查 release notes使用towncrier构建 release note 并提交更改。该操作会清空doc/release/upcoming_changes中的所有 fragment并生成doc/release/version-note.rsttowncrier build --version version git commit -mCreate release note随后检查 release notes 是否最新并补充 Highlights 章节通常包括主要新特性major new features已废弃与已移除的功能支持的 Python 版本对 SciPy 而言支持的 NumPy 版本近期展望outlook for the near future。三、分支创建演练BRANCH_WALKTHROUGH以下命令来自 doc/BRANCH_WALKTHROUGH.rst以创建 NumPy 2.3.x 分支为例实际使用时请把 2.3/2.4 替换为正确的版本号。在切分支之前最好把.mailmap更新到尽量新的状态可能耗时数周。3.1 创建分支仅在开启一个新的 maintenance 分支时才需要这一步。main 分支上新一轮开发周期的起点应打一个 annotated taggit checkout main git pull upstream main git commit --allow-empty -mREL: Begin NumPy 2.4.0 development git push upstream HEAD若因新 PR 被合入导致 push 失败git pull --rebase upstream然后重试 push。push 成功后打 tag 并推送git tag -a -s v2.4.0.dev0 -mBegin NumPy 2.4.0 development git push upstream v2.4.0.dev0接着基于 tag 的父提交创建 maintenance 分支并推送git branch maintenance/2.3.x HEAD^ git push upstream maintenance/2.3.x3.2 准备 main 分支以继续开发创建一个 PR 分支来准备main的后续开发git checkout -b prepare-main-for-2.4.0-development v2.4.0.dev0删除 release note fragments这些属于已发布的 2.3.xgit rm doc/release/upcoming_changes/[0-9]*.*.rst从模板创建新版本 release notes 骨架并加入索引cp doc/source/release/template.rst doc/source/release/2.4.0-notes.rst gvim doc/source/release/2.4.0-notes.rst # 填入正确版本号 git add doc/source/release/2.4.0-notes.rst gvim doc/source/release.rst # 把新 notes 加入索引 git add doc/source/release.rst更新 numpy/_core/code_generators/cversions.txt加入当前版本。此阶段一般没有新的 hash 需要处理只需按既有惯例添加注释如# Version 22 (NumPy 2.5.0) Opaque PyObject ABI support ...这种格式gvim numpy/_core/code_generators/cversions.txt git add numpy/_core/code_generators/cversions.txt最后检查、提交并推送然后创建 PRgit status # 检查工作 git commit -mREL: Prepare main for NumPy 2.4.0 development git push origin HEAD四、正式发布逐步演练RELEASE_WALKTHROUGHdoc/RELEASE_WALKTHROUGH.rst 以 NumPy 2.4.0首个使用numpy/numpy-release仓库的 feature release为例命令可直接复制使用但务必把2.4.0替换为实际版本。该文应与总体发布指南配合阅读。4.1 环境准备开始发布前使用requirements/*_requirements.txt确保已安装所需软件多数可用 pip 安装部分需要 apt-get、dnf 等系统包管理器。还需要 GitHub personal access tokenPAT用于推送文档。可通过 Git keyring 存储该 token 以简化操作。4.2 发布前检查清单增删 Python 版本除修改 pyproject.toml 中的最低版本外还要编辑多个配置与 CI 文件。这些改动应在针对 main 的普通 PR 中完成必要时 backport。当前策略是在 manylinux 与 cibuildwheel 支持新 Python 后于该 Python 首个 RC 之后发布对应 wheel。Backport 拉取请求标记给本 release 的更改必须 backport 到maintenance/2.4.x分支。更新 2.4.0 Milestones查看带有 2.4.0 milestone 的 issues/PRs将其推后到更晚版本或移除 milestone也可能需要新增 milestone。检查 numpy-release 仓库重点核对.github/workflows/wheels.yml中的cibuildwheel版本以及openblas_requirements.txt中的 OpenBLAS 版本。4.3 创建 release PR通常需要更新或创建四类文件changelogrelease notes.mailmappyproject.toml。这些改动应作为针对 maintenance 分支的普通 PR 提交也可以顺带包含其他小的杂项修复。典型的提交信息REL: Prepare for the NumPy 2.4.0 release - Create 2.4.0-changelog.rst. - Update 2.4.0-notes.rst. - Update .mailmap. - Update pyproject.toml设置发布版本检查 pyproject.toml设置发布版本号并按需更新 classifiergvim pyproject.toml检查 release.rst确保 doc/source/release.rst 中有新 release notes 的条目gvim doc/source/release.rst生成 changelog使用spin changelog收集已合并的 PR 并格式化为发布用 changelogspin changelog $GITHUB v2.3.0..maintenance/2.4.x doc/changelog/2.4.0-changelog.rst其中GITHUB是你的 GitHub access token。生成后需要检查非标准贡献者名字应通过更新.mailmap修复工作量大建议提前多次试跑并通过 GitHub issue 联系当事人补充信息PR 标题中的链接需要移除或替换为等宽文本因为它们转成 Markdown 后效果不好。完成 release notes如果 doc/release/upcoming_changes/ 中还有 release notes 片段运行spin notes将其合并进doc/source/release/notes-towncrier.rst并删除片段spin notes gvim doc/source/release/notes-towncrier.rst doc/source/release/2.4.0-notes.rstnotes-towncrier的内容并入正式 release notes 后应移除其中的.. include:: notes-towncrier.rst指令。notes 总需要一些修正撰写引言、突出重要变更。patch release 可把 changelog 文本追加进去但首发版本因内容太长一般不追加。可参考历史 release notes 的写法。测试 wheel 构建release PR 合并后在浏览器中打开numpy-release仓库用 Actions 页面的Run workflow按钮在maintenance/2.4.x分支上手动触发 workflow并确保environment下拉框中上传目标为none。wheel 构建约需 1 小时GitHub 有时很慢。若有无关原因导致的构建失败可在 GitHub Actions UI 中用re-run failed重跑。构建完成后检查产物数量与 wheel 命名是否正确确认无误后再进入正式发布。4.4 发布操作步骤下文中的upstream指 GitHub 上的根仓库origin指你个人账号下的 fork。若你只是直接 clone 而没有 fork可在.git/config中添加upstream。步骤 1为发布提交打 taggit checkout maintenance/2.4.x git pull upstream maintenance/2.4.x git submodule update git clean -xdfq健全性检查跑完整测试套件python3 -m spin test -m full打 annotated、签名的 tag 并推送需要 numpy 仓库写权限git tag -a -s v2.4.0 -mNumPy 2.4.0 release git push upstream v2.4.0出错需删除 tag 时git tag -d v2.4.0 git push --delete upstream v2.4.0步骤 2构建 wheels 与 sdist在numpy-release仓库中手动触发 workflow同前但这次environment下拉框选择pypi。构建约 1 小时检查产物数量与命名后触发上传。步骤 3上传文件到 GitHub Releases在 GitHub 的 releases 页面找到v2.4.0tag点击编辑将标题更新为 v2.4.0 ( )。添加文件有两种方式可编辑文本窗口和二进制上传。文本窗口需要 Markdown因此要把 release notes 从 rst 转成 mdpython tools/write_release.py 2.4.0该脚本见 tools/write_release.py会把doc/source/release/2.4.0-notes.rst复制为release/README.rst并调用 Pandoc 转换成release/README.md需要系统安装 Pandoc。检查结果可能需要修复换行与链接改为等宽文本然后把内容粘贴到文本窗口。接着从 PyPI 下载 sdistnumpy-2.4.0.tar.gz并以二进制文件上传到 GitHub不能用 pip 完成上传release/README.rst为二进制文件上传doc/changelog/2.4.0-changelog.rst为二进制文件若为预发布版本勾选 pre-release 按钮点击Publish release。注意请确保 3 个文件都已上传且 release 文本完整。Releases 被配置为不可变immutable出错后难以轻易修复。步骤 4上传文档到 numpy.org预发布跳过需要 GitHub personal access token 来推送更新。此步骤仅对正式版必需预发布和大部分 patch release 可跳过。make merge-doc通过spin docs merge-doc会把numpy/doc仓库 clone 到doc/build/merge并用新文档更新它git clean -xdfq git co v2.5.0 rm -rf doc/build # 希望版本是最新的 python -m spin docs merge-doc --build如需构建 PDF 文档python -m spin docs latex pushd doc/build/latex make all-pdf popd cp doc/build/latex/numpy-user.pdf doc/build/latex/numpy-ref.pdf doc/build/merge/2.5/若这是一个新的 release 系列需要在doc/build/merge/index.html首页的 insert here 注释之后新增一节pushd doc/build/merge gvim index.html /insert here同时更新版本切换器 json 文件加入新版本并更新标记为(stable)与preferred的版本gvim _static/versions.json python3 update.py可以在浏览器中试运行新文档检查链接是否正常版本下拉框不会变因为它从 numpy.org 拉取信息firefox index.html # 或 google-chrome 等更新 stable 软链接ln -sfn 2.5 stable ls -l stable # 检查链接一切满意后提交并推送git checkout -b v2.5 git add 2.5/*.pdf git commit -a -mAdd documentation for v2.5.0 git push gitgithub.com:numpy/doc popd步骤 5将 maintenance 分支重置为开发状态预发布跳过为下一版本创建 release notes 骨架并设置版本git checkout -b begin-2.4.1 maintenance/2.4.x cp doc/source/release/template.rst doc/source/release/2.4.1-notes.rst gvim doc/source/release/2.4.1-notes.rst git add doc/source/release/2.4.1-notes.rst添加新 release notes 的链接并更新 pyproject.toml 中的versiongvim doc/source/release.rst gvim pyproject.toml提交提交信息中注明涉及的文件并添加[skip actions]行后推送并创建 PRgit commit -a -mMAINT: Prepare 2.4.x for further development git rebase -i HEAD^ git push origin HEAD该 PR 应被快速合并。步骤 6在 numpy.org 发布公告预发布跳过假设你已 forknumpy/numpy.orgcd ../numpy.org git checkout main git pull upstream main git checkout -b announce-numpy-2.4.0 gvim content/en/news.md所有版本在页面底部加一行链接参考既有链接的写法对于每个周期的*.0版本在顶部新增一节简述新特性并把 news 链接指向该节更新 news.md 顶部的 newsHeader 与日期字段同时编辑content/en/config.yaml第 14 行的 buttonText。提交推送并创建 PRgit commit -a -mannounce the NumPy 2.4.0 release git push origin HEAD步骤 7向邮件列表公告发布应公告到 numpy-discussion 与 python-announce-list 邮件列表可参考往期公告模板。贡献者与 PR 列表与生成 release notes 时相同。若交叉发布务必把 python-announce-list 放在 BCC 中避免回复发到该列表。步骤 8发布后更新 main预发布跳过checkout main 并前向移植文档改动git checkout -b post-2.4.0-release-update main git checkout maintenance/2.4.x doc/source/release/2.4.0-notes.rst git checkout maintenance/2.4.x doc/changelog/2.4.0-changelog.rst git checkout maintenance/2.4.x .mailmap # 仅当发布时更新过 gvim doc/source/release.rst # 为新 notes 添加链接 git status # 提交前检查状态 git commit -a -mMAINT: Update main after 2.4.0 release. git push origin HEAD然后创建 PR。五、发布流程中的关键工具与仓库文件速查spinNumPy 的开发者命令行工具见 doc/source/dev/spin.rst统一封装构建、测试、文档等工作流。发布流程中用到的子命令spin test -m full全量测试、spin changelog生成 changelog、spin notes合并 notes fragments、spin docs merge-doc --build构建并合并文档。tools/write_release.py将version-notes.rst复制为release/README.rst并用 Pandoc 翻译为release/README.md供 GitHub Releases 文本窗口使用。doc/release/upcoming_changes/存放 changelog/release notes 片段fragments发布时由towncrier/spin notes合并清理。numpy/_core/meson.build维护C_API_VERSION与C_ABI_VERSION两处版本号。numpy/_core/code_generators/cversions.txt与 numpy/_core/cversions.py记录并校验 API hash。numpy/_core/include/numpy/numpyconfig.h定义各版本NPY_X_Y_API_VERSION宏。六、总结NumPy 的版本发布是一个高度流程化、且大部分环节由 CI 与专用脚本支撑的过程分支创建遵循空提交打 tag → 基于父提交开 maintenance 分支 → main 进入下一轮开发的固定模式正式发布则依次完成 changelog/release notes 生成、C API 版本三处同步、wheel 构建验证、tag 推送、PyPI 上传、GitHub Releases 文件补全、文档部署与多通道公告。本文所述命令与文件路径均可在当前仓库中直接找到对应实现实际发布时请以 doc/source/dev/releasing.rst 引用的三份手册为准并将示例版本号替换为真实版本。赞分享科学计算数据分析【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址https://gitcode.com/gh_mirrors/nu/numpy点击查看免费下载相关推荐SymPy 版本发布全流程指南从 release 分支、Docker 构建到 GitHub/PyPI 上传SymPy 版本发布全流程指南从 release 分支、Docker 构建到 GitHub/PyPI 上传 SymPy 作为一套纯 Python 编写的计算机科学计算符号运算Fan Control 风扇控制教程3 步搞定深夜机箱噪音Fan Control 风扇控制教程3 步搞定深夜机箱噪音 凌晨两点你起身去洗手间机箱风扇像拖拉机一样嗡嗡作响明明电脑已经闲置了一整晚。Fan Cont桌面应用智能硬件Apache Superset 版本发布全流程指南从 RC 打包、社区投票到 PyPI/Docker/npm 发布Apache Superset 版本发布全流程指南从 RC 打包、社区投票到 PyPI/Docker/npm 发布 Apache Superset 采用 Ap数据可视化数据分析后端上一篇RoboPOJOGenerator性能优化处理大规模JSON数据的高效策略下一篇React Modal Sheet 使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 NumPy 版本发布全流程指南：从分支创建到 PyPI 上传与社区公告
科学计算数据分析【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址https://gitcode.com/gh_mirrors/nu/numpy点击查看免费下载导读本文基于 doc/source/dev/releasing.rst 梳理 NumPy 官方完整的版本发布流程。该索引文档通过.. include::引入了三份核心操作手册——doc/HOWTO_RELEASE.rst总体发布指南、doc/RELEASE_WALKTHROUGH.rst以 2.4.0 为实例的逐步发布演练与 doc/BRANCH_WALKTHROUGH.rst分支创建演练。读完本文你将掌握 NumPy 从创建 maintenance 分支、检查 C API 版本、生成 changelog 与 release notes到构建/上传 wheel、发布到 PyPI 与 GitHub Releases、部署文档并对外公告的完整发布链路以及每个环节对应的仓库文件与命令。一、发布前的总体准备与平台支持1.1 构建与发布信息NumPy 构建二进制发行版所需的信息主要来自三份文档即本索引所引用的三份文件doc/HOWTO_RELEASE.rst——发布总体说明覆盖平台支持、工具链、OpenBLAS、文档构建与 PyPI 上传doc/RELEASE_WALKTHROUGH.rst——以 NumPy 2.4.0 在 Linux 上的发布为实例的逐步操作演练doc/BRANCH_WALKTHROUGH.rst——以 NumPy 2.3.x 分支为实例的维护分支创建演练。另外从源码构建的详细说明见文档目录的 building 相关章节doc/source/building/。1.2 支持的平台与版本Python 版本策略NEP 29规定了最低支持哪些 Python 版本。实际发布时为了避免给其他项目带来麻烦NumPy 通常会在该最低要求的基础上再延长一段时间支持某个 Python 版本具体由发布经理release manager酌情决定。macOS目标支持与 Python.org 和cibuildwheel对给定 Python 版本所支持的范围一致的 macOS 版本。构建的 macOS wheel 兼容常见 Python 安装方式python.org 官方安装包、python-build-standaloneuv安装所用、系统 Python、conda-forge、Homebrew 和 MacPorts。Windows同时构建 32 位和 64 位 wheel支持 Windows 7、8、10。截至 2025 年 8 月x86/x86-64 使用 MSVCarm64 使用 Clang-cl构建基于cibuildwheel和 GitHub Actions。Linux在 PyPI 上发布面向 x86-64 与 aarch64 的manylinux和musllinuxwheel目前不提供 32 位平台 wheel目标支持最低的非 EOLEnd-of-Life版本并大致与cibuildwheel的节奏同步升级。BSD / Solaris / AIXPyPI 上不提供二进制 wheel但从源码构建在这些平台上可以正常工作。1.3 工具链构建 wheel 使用的工具链Linux使用manylinux/musllinuxDocker 镜像中的默认编译器通常是较新的 GCCmacOS使用 GitHub Actions runner 镜像上安装的 Apple Clang 与 XCodeWindowsx86 与 x86-64 使用 GitHub Actions runner 镜像上安装的默认 MSVC / Visual Studio 工具链。历史上为规避静态libnpymath库对 SciPy 造成的问题有时需要使用较旧工具链——如需确定确切版本号请检查numpy/numpy-release仓库代码和 CI 日志。从源码构建时的最低编译器版本要求记录在仓库根目录的meson.build文件中NumPy 2.x 已全面迁移到 Meson 构建系统。1.4 OpenBLAS、文档构建与 PyPI 上传OpenBLAS大多数 wheel 链接到由 openblas-libs 仓库提供的 OpenBLAS 版本。共享库或 DLL被打包进 wheel并重命名以避免与文件系统中其他 OpenBLAS 共享对象发生名称冲突。构建文档不再构建 PDF 文件构建 HTML 文档的要求与日常开发相同。具体逐步操作见doc/RELEASE_WALKTHROUGH.rst。上传 PyPI在 PyPI 上创建 release、上传 wheel 与 sdist 的流程已由 CI 自动化使用 PyPI 的 trusted publishing可信发布机制。详见numpy/numpy-release仓库 README 与doc/RELEASE_WALKTHROUGH.rst。生成作者/PR 列表需要一个 GitHub personal access token以便脚本访问 NumPy GitHub 仓库。有了 token 后可通过spin changelog生成作者/PR 变更日志该命令可能额外需要gitpython、pygithub等包。1.5 发布的内容物PyPI发布多个平台的 wheel 和一个 sdist源码包GitHub Releases发布与 PyPI 相同的 sdist因为 GitHub 自动生成的源码归档不完整以及 release notes 和 changelog。二、总体发布流程HOWTO_RELEASE2.1 确定发布日程典型的 feature release 节奏是两个发布候选RC加一个正式版。发布时间最好先在邮件列表上讨论以便大家及时合入各自的提交。日期确定后创建新的maintenance/x.y.z分支在 main 分支上为新版本添加空的 release notes更新 issue 跟踪器上的 Milestones。2.2 检查废弃项Deprecations在创建 release 分支之前应检查所有应移除的已废弃代码是否确实被移除所有新增的废弃项是否在 docstring 或 DeprecationWarning 中明确说明了移除版本。2.3 检查 C API 版本号C API 版本需要在三处同步维护文件作用numpy/_core/meson.build定义C_API_VERSION与C_ABI_VERSIONnumpy/_core/code_generators/cversions.txt记录各 API 版本对应的 hashnumpy/_core/include/numpy/numpyconfig.h定义NPY_X_Y_API_VERSION宏具体分三步第一步判断 API 是否变化。只有当前 API 编译出的代码能向后兼容上一发布版本才认为 API 未变。任何对 C 结构的修改或对公共接口的增补都会使 API 不再向后兼容此时需要递增numpy/_core/meson.build中的C_API_VERSION。当前仓库中该值为0x00000016对应 NumPy 2.5/2.6 系列。第二步更新 cversions.txt。如果第一步的C_API_VERSION变了或者 API 的 hash 变了就需要更新 numpy/_core/code_generators/cversions.txt。校验 hash 的方法是运行 numpy/_core/cversions.py它会调用code_generators/genapi.fullapi_hash(full_api)打印当前 API hashpython numpy/_core/cversions.py将该 hash 与cversions.txt最后一条记录比对若不同则 hash 已变化。此时需要结合合适的C_API_VERSION与 hash 在cversions.txt中新增一条记录如果 API 版本未变但 hash 变了则需要注释掉该 API 版本对应的上一条记录。典型例子是 NumPy 1.9 添加了注解hash 变了但 API 与 1.8 相同。注意 hash 只是 API 变化的校验手段并非决定性依据。如果第 1、2 步都做对了编译 release 时不应出现 API mismatch detect at the beginning of the build 警告。当前 cversions.txt 中记录了从 0x00000001 到 0x00000016NumPy 2.5.0 引入 opaque PyObject ABI 支持与NPY_DT_legacy_descriptor_proto支持NumPy 2.6.0 无变化的完整历史可作为格式参考。第三步更新 numpyconfig.h。在 numpy/_core/include/numpy/numpyconfig.h 中新增NPY_X_Y_API_VERSION宏X、Y 为 release 的主次版本号。宏的值只在 include 文件中有函数或宏被废弃时才需要比上一版本增加。例如当前文件中的系列NPY_2_3_API_VERSION 0x00000014、NPY_2_4_API_VERSION 0x00000015、NPY_2_5_API_VERSION 0x00000016、NPY_2_6_API_VERSION 0x000000162.6 未变化故值相同。另外numpy/_core/meson.build 中的C_ABI_VERSION当前为0x02000000只应在 major release 时更新——这与C_API_VERSION不同二进制兼容被打破时两者都要递增而仅 API 增加但保持二进制兼容时只递增C_API_VERSION。构建时该值会写入NPY_ABI_VERSION/NPY_API_VERSION宏。2.4 检查 release notes使用towncrier构建 release note 并提交更改。该操作会清空doc/release/upcoming_changes中的所有 fragment并生成doc/release/version-note.rsttowncrier build --version version git commit -mCreate release note随后检查 release notes 是否最新并补充 Highlights 章节通常包括主要新特性major new features已废弃与已移除的功能支持的 Python 版本对 SciPy 而言支持的 NumPy 版本近期展望outlook for the near future。三、分支创建演练BRANCH_WALKTHROUGH以下命令来自 doc/BRANCH_WALKTHROUGH.rst以创建 NumPy 2.3.x 分支为例实际使用时请把 2.3/2.4 替换为正确的版本号。在切分支之前最好把.mailmap更新到尽量新的状态可能耗时数周。3.1 创建分支仅在开启一个新的 maintenance 分支时才需要这一步。main 分支上新一轮开发周期的起点应打一个 annotated taggit checkout main git pull upstream main git commit --allow-empty -mREL: Begin NumPy 2.4.0 development git push upstream HEAD若因新 PR 被合入导致 push 失败git pull --rebase upstream然后重试 push。push 成功后打 tag 并推送git tag -a -s v2.4.0.dev0 -mBegin NumPy 2.4.0 development git push upstream v2.4.0.dev0接着基于 tag 的父提交创建 maintenance 分支并推送git branch maintenance/2.3.x HEAD^ git push upstream maintenance/2.3.x3.2 准备 main 分支以继续开发创建一个 PR 分支来准备main的后续开发git checkout -b prepare-main-for-2.4.0-development v2.4.0.dev0删除 release note fragments这些属于已发布的 2.3.xgit rm doc/release/upcoming_changes/[0-9]*.*.rst从模板创建新版本 release notes 骨架并加入索引cp doc/source/release/template.rst doc/source/release/2.4.0-notes.rst gvim doc/source/release/2.4.0-notes.rst # 填入正确版本号 git add doc/source/release/2.4.0-notes.rst gvim doc/source/release.rst # 把新 notes 加入索引 git add doc/source/release.rst更新 numpy/_core/code_generators/cversions.txt加入当前版本。此阶段一般没有新的 hash 需要处理只需按既有惯例添加注释如# Version 22 (NumPy 2.5.0) Opaque PyObject ABI support ...这种格式gvim numpy/_core/code_generators/cversions.txt git add numpy/_core/code_generators/cversions.txt最后检查、提交并推送然后创建 PRgit status # 检查工作 git commit -mREL: Prepare main for NumPy 2.4.0 development git push origin HEAD四、正式发布逐步演练RELEASE_WALKTHROUGHdoc/RELEASE_WALKTHROUGH.rst 以 NumPy 2.4.0首个使用numpy/numpy-release仓库的 feature release为例命令可直接复制使用但务必把2.4.0替换为实际版本。该文应与总体发布指南配合阅读。4.1 环境准备开始发布前使用requirements/*_requirements.txt确保已安装所需软件多数可用 pip 安装部分需要 apt-get、dnf 等系统包管理器。还需要 GitHub personal access tokenPAT用于推送文档。可通过 Git keyring 存储该 token 以简化操作。4.2 发布前检查清单增删 Python 版本除修改 pyproject.toml 中的最低版本外还要编辑多个配置与 CI 文件。这些改动应在针对 main 的普通 PR 中完成必要时 backport。当前策略是在 manylinux 与 cibuildwheel 支持新 Python 后于该 Python 首个 RC 之后发布对应 wheel。Backport 拉取请求标记给本 release 的更改必须 backport 到maintenance/2.4.x分支。更新 2.4.0 Milestones查看带有 2.4.0 milestone 的 issues/PRs将其推后到更晚版本或移除 milestone也可能需要新增 milestone。检查 numpy-release 仓库重点核对.github/workflows/wheels.yml中的cibuildwheel版本以及openblas_requirements.txt中的 OpenBLAS 版本。4.3 创建 release PR通常需要更新或创建四类文件changelogrelease notes.mailmappyproject.toml。这些改动应作为针对 maintenance 分支的普通 PR 提交也可以顺带包含其他小的杂项修复。典型的提交信息REL: Prepare for the NumPy 2.4.0 release - Create 2.4.0-changelog.rst. - Update 2.4.0-notes.rst. - Update .mailmap. - Update pyproject.toml设置发布版本检查 pyproject.toml设置发布版本号并按需更新 classifiergvim pyproject.toml检查 release.rst确保 doc/source/release.rst 中有新 release notes 的条目gvim doc/source/release.rst生成 changelog使用spin changelog收集已合并的 PR 并格式化为发布用 changelogspin changelog $GITHUB v2.3.0..maintenance/2.4.x doc/changelog/2.4.0-changelog.rst其中GITHUB是你的 GitHub access token。生成后需要检查非标准贡献者名字应通过更新.mailmap修复工作量大建议提前多次试跑并通过 GitHub issue 联系当事人补充信息PR 标题中的链接需要移除或替换为等宽文本因为它们转成 Markdown 后效果不好。完成 release notes如果 doc/release/upcoming_changes/ 中还有 release notes 片段运行spin notes将其合并进doc/source/release/notes-towncrier.rst并删除片段spin notes gvim doc/source/release/notes-towncrier.rst doc/source/release/2.4.0-notes.rstnotes-towncrier的内容并入正式 release notes 后应移除其中的.. include:: notes-towncrier.rst指令。notes 总需要一些修正撰写引言、突出重要变更。patch release 可把 changelog 文本追加进去但首发版本因内容太长一般不追加。可参考历史 release notes 的写法。测试 wheel 构建release PR 合并后在浏览器中打开numpy-release仓库用 Actions 页面的Run workflow按钮在maintenance/2.4.x分支上手动触发 workflow并确保environment下拉框中上传目标为none。wheel 构建约需 1 小时GitHub 有时很慢。若有无关原因导致的构建失败可在 GitHub Actions UI 中用re-run failed重跑。构建完成后检查产物数量与 wheel 命名是否正确确认无误后再进入正式发布。4.4 发布操作步骤下文中的upstream指 GitHub 上的根仓库origin指你个人账号下的 fork。若你只是直接 clone 而没有 fork可在.git/config中添加upstream。步骤 1为发布提交打 taggit checkout maintenance/2.4.x git pull upstream maintenance/2.4.x git submodule update git clean -xdfq健全性检查跑完整测试套件python3 -m spin test -m full打 annotated、签名的 tag 并推送需要 numpy 仓库写权限git tag -a -s v2.4.0 -mNumPy 2.4.0 release git push upstream v2.4.0出错需删除 tag 时git tag -d v2.4.0 git push --delete upstream v2.4.0步骤 2构建 wheels 与 sdist在numpy-release仓库中手动触发 workflow同前但这次environment下拉框选择pypi。构建约 1 小时检查产物数量与命名后触发上传。步骤 3上传文件到 GitHub Releases在 GitHub 的 releases 页面找到v2.4.0tag点击编辑将标题更新为 v2.4.0 ( )。添加文件有两种方式可编辑文本窗口和二进制上传。文本窗口需要 Markdown因此要把 release notes 从 rst 转成 mdpython tools/write_release.py 2.4.0该脚本见 tools/write_release.py会把doc/source/release/2.4.0-notes.rst复制为release/README.rst并调用 Pandoc 转换成release/README.md需要系统安装 Pandoc。检查结果可能需要修复换行与链接改为等宽文本然后把内容粘贴到文本窗口。接着从 PyPI 下载 sdistnumpy-2.4.0.tar.gz并以二进制文件上传到 GitHub不能用 pip 完成上传release/README.rst为二进制文件上传doc/changelog/2.4.0-changelog.rst为二进制文件若为预发布版本勾选 pre-release 按钮点击Publish release。注意请确保 3 个文件都已上传且 release 文本完整。Releases 被配置为不可变immutable出错后难以轻易修复。步骤 4上传文档到 numpy.org预发布跳过需要 GitHub personal access token 来推送更新。此步骤仅对正式版必需预发布和大部分 patch release 可跳过。make merge-doc通过spin docs merge-doc会把numpy/doc仓库 clone 到doc/build/merge并用新文档更新它git clean -xdfq git co v2.5.0 rm -rf doc/build # 希望版本是最新的 python -m spin docs merge-doc --build如需构建 PDF 文档python -m spin docs latex pushd doc/build/latex make all-pdf popd cp doc/build/latex/numpy-user.pdf doc/build/latex/numpy-ref.pdf doc/build/merge/2.5/若这是一个新的 release 系列需要在doc/build/merge/index.html首页的 insert here 注释之后新增一节pushd doc/build/merge gvim index.html /insert here同时更新版本切换器 json 文件加入新版本并更新标记为(stable)与preferred的版本gvim _static/versions.json python3 update.py可以在浏览器中试运行新文档检查链接是否正常版本下拉框不会变因为它从 numpy.org 拉取信息firefox index.html # 或 google-chrome 等更新 stable 软链接ln -sfn 2.5 stable ls -l stable # 检查链接一切满意后提交并推送git checkout -b v2.5 git add 2.5/*.pdf git commit -a -mAdd documentation for v2.5.0 git push gitgithub.com:numpy/doc popd步骤 5将 maintenance 分支重置为开发状态预发布跳过为下一版本创建 release notes 骨架并设置版本git checkout -b begin-2.4.1 maintenance/2.4.x cp doc/source/release/template.rst doc/source/release/2.4.1-notes.rst gvim doc/source/release/2.4.1-notes.rst git add doc/source/release/2.4.1-notes.rst添加新 release notes 的链接并更新 pyproject.toml 中的versiongvim doc/source/release.rst gvim pyproject.toml提交提交信息中注明涉及的文件并添加[skip actions]行后推送并创建 PRgit commit -a -mMAINT: Prepare 2.4.x for further development git rebase -i HEAD^ git push origin HEAD该 PR 应被快速合并。步骤 6在 numpy.org 发布公告预发布跳过假设你已 forknumpy/numpy.orgcd ../numpy.org git checkout main git pull upstream main git checkout -b announce-numpy-2.4.0 gvim content/en/news.md所有版本在页面底部加一行链接参考既有链接的写法对于每个周期的*.0版本在顶部新增一节简述新特性并把 news 链接指向该节更新 news.md 顶部的 newsHeader 与日期字段同时编辑content/en/config.yaml第 14 行的 buttonText。提交推送并创建 PRgit commit -a -mannounce the NumPy 2.4.0 release git push origin HEAD步骤 7向邮件列表公告发布应公告到 numpy-discussion 与 python-announce-list 邮件列表可参考往期公告模板。贡献者与 PR 列表与生成 release notes 时相同。若交叉发布务必把 python-announce-list 放在 BCC 中避免回复发到该列表。步骤 8发布后更新 main预发布跳过checkout main 并前向移植文档改动git checkout -b post-2.4.0-release-update main git checkout maintenance/2.4.x doc/source/release/2.4.0-notes.rst git checkout maintenance/2.4.x doc/changelog/2.4.0-changelog.rst git checkout maintenance/2.4.x .mailmap # 仅当发布时更新过 gvim doc/source/release.rst # 为新 notes 添加链接 git status # 提交前检查状态 git commit -a -mMAINT: Update main after 2.4.0 release. git push origin HEAD然后创建 PR。五、发布流程中的关键工具与仓库文件速查spinNumPy 的开发者命令行工具见 doc/source/dev/spin.rst统一封装构建、测试、文档等工作流。发布流程中用到的子命令spin test -m full全量测试、spin changelog生成 changelog、spin notes合并 notes fragments、spin docs merge-doc --build构建并合并文档。tools/write_release.py将version-notes.rst复制为release/README.rst并用 Pandoc 翻译为release/README.md供 GitHub Releases 文本窗口使用。doc/release/upcoming_changes/存放 changelog/release notes 片段fragments发布时由towncrier/spin notes合并清理。numpy/_core/meson.build维护C_API_VERSION与C_ABI_VERSION两处版本号。numpy/_core/code_generators/cversions.txt与 numpy/_core/cversions.py记录并校验 API hash。numpy/_core/include/numpy/numpyconfig.h定义各版本NPY_X_Y_API_VERSION宏。六、总结NumPy 的版本发布是一个高度流程化、且大部分环节由 CI 与专用脚本支撑的过程分支创建遵循空提交打 tag → 基于父提交开 maintenance 分支 → main 进入下一轮开发的固定模式正式发布则依次完成 changelog/release notes 生成、C API 版本三处同步、wheel 构建验证、tag 推送、PyPI 上传、GitHub Releases 文件补全、文档部署与多通道公告。本文所述命令与文件路径均可在当前仓库中直接找到对应实现实际发布时请以 doc/source/dev/releasing.rst 引用的三份手册为准并将示例版本号替换为真实版本。赞分享科学计算数据分析【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址https://gitcode.com/gh_mirrors/nu/numpy点击查看免费下载相关推荐SymPy 版本发布全流程指南从 release 分支、Docker 构建到 GitHub/PyPI 上传SymPy 版本发布全流程指南从 release 分支、Docker 构建到 GitHub/PyPI 上传 SymPy 作为一套纯 Python 编写的计算机科学计算符号运算Fan Control 风扇控制教程3 步搞定深夜机箱噪音Fan Control 风扇控制教程3 步搞定深夜机箱噪音 凌晨两点你起身去洗手间机箱风扇像拖拉机一样嗡嗡作响明明电脑已经闲置了一整晚。Fan Cont桌面应用智能硬件Apache Superset 版本发布全流程指南从 RC 打包、社区投票到 PyPI/Docker/npm 发布Apache Superset 版本发布全流程指南从 RC 打包、社区投票到 PyPI/Docker/npm 发布 Apache Superset 采用 Ap数据可视化数据分析后端上一篇RoboPOJOGenerator性能优化处理大规模JSON数据的高效策略下一篇React Modal Sheet 使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考