开发工具文档【免费下载链接】quarto-cliOpen-source scientific and technical publishing system built on Pandoc.项目地址https://gitcode.com/gh_mirrors/qu/quarto-cli点击查看免费下载Quartoquarto-cli的版本发布分为两条路径新 major/minor 版本如 1.10 → 1.11走prerelease → stable的完整周期而稳定分支v1.x上的补丁版本patch release如 1.11.5则通过本文所述的稳定版检查清单快速迭代。本文以仓库中的 checklist-make-a-new-stable-quarto-release.md 为骨架逐步骤拆解一次稳定补丁发布要执行的测试、构建、官网同步、PyPI、Chocolatey 发布与 changelog 整理并结合 create-release.yml、publish-cloudsmith.yml、test-smokes-parallel.yml 等真实工作流源码讲清每一步背后的自动化原理。读完本文你将掌握如何在 quarto-cli 仓库中完整发布一个稳定补丁版本并理解哪些环节自动完成、哪些环节必须人工介入。前置理解稳定分支上的补丁版本稳定版stable release发布与预发布prerelease发布的关键差异体现在两条清单的分工上新周期major/minor发布走 checklist-make-a-new-quarto-release.md在main上创建v1.x分支、切出 backports 脚手架、构建 prerelease、最终把预发布构建重新标记为稳定版本文的稳定版清单则处理稳定分支v1.x上的后续补丁此时分支已经存在测试、构建、发布全部在既有v1.x分支上进行create-release.yml直接以pre-releasefalse触发。一个直观的证据是仓库当前状态configuration文件中QUARTO_VERSION1.11根目录 version.txt 记录1.11.5news/changelog-1.11.md为当前版本的 changelog——这正是1.11 主版本已发布、正在稳定分支上迭代补丁的典型形态。发布稳定版的核心原则可以概括为先验证测试→ 再构建安装包→ 再分发官网/PyPI/Chocolatey/社区渠道→ 最后收尾changelog。以下按此顺序展开。第 1 步在稳定分支上运行冒烟测试发布的第一个动作是确保稳定分支上的测试全部通过。清单要求在 GitHub Actions 的 Parallel Smokes Tests 工作流中将 Use workflow from... 下拉框切换为当前的v1.x稳定分支后点击 Run Workflow。从源码看test-smokes-parallel.yml 明确支持稳定分支场景其pull_request与push触发器均覆盖v[1-9].[0-9]分支模式并注释 run also on released version branch (for patch releases)。该工作流通过./run-parallel-tests.sh -n${{ inputs.nBuckets }}把测试按历史耗时切分为多个 bucket 并行执行默认 10 个CI 中默认 20任何一个 bucket 失败都代表大范围功能受损因此它是发布前最重要的质量闸门。值得注意清单要求手工指定分支运行而不是依赖 PR 触发。原因是稳定分支通常只接收 backport 的少量提交发布前需要一次针对分支最新提交的完整回归。第 2 步构建并发布稳定版安装程序Build Installers测试通过后进入核心步骤——触发 Build Installers 工作流即 create-release.yml。在 Actions 页面选择该工作流后关键参数设置如下参数稳定版要求说明Use workflow from...当前v1.x稳定分支以稳定分支代码构建而非mainPre-release取消勾选确保未勾选决定 GitHub Release 是否标记为预发布稳定版必须为falsePublish release勾选确保已勾选决定是否真正创建 Release 并推送 tag除了这两个核心开关create-release.yml 的workflow_dispatch还暴露了更多可选输入稳定版发布一般保持默认即可osall/linux/windows/macos默认all选择构建哪些平台工作流内部有保护逻辑——当publish-releasetrue且os ! all时会直接报错退出防止单平台构建却发布正式 Releasesmoke-artifacts-only仅构建 Linux amd64 tarball 与签名后的 Windows zip 供内置版本测试使用且要求publish-releasefalse二者同时勾选会触发 Fail on publish-release smoke-artifacts-only 检查skip-auto-smoke跳过test-smokes-built.yml自动触发的内置版本冒烟测试。工作流触发后从源码可以看到一条完整的自动化流水线configure 任务读取根目录configurationQUARTO_VERSION与version.txt计算出完整版本号version_full major.minor.build_number若version.txt中的主次版本与QUARTO_VERSION一致补丁发布场景则build_number在原基础上 1生成 release note更新version.txt并提交同时打上v版本号的 Git tag并行构建 Linuxamd64/arm64 的 tarball、deb、rpm、WindowsMSI zip含代码签名、macOSpkg tar.gz含签名与公证产物对 Linux tarball、Windows zip、macOS zip 分别执行quarto check/quarto --paths/quarto --version冒烟验证publish-release 任务汇总所有产物计算 sha256 checksums通过softprops/action-gh-release创建 GitHub Releaseprerelease取值即来自pre-release输入若流程失败cleanup-when-failure任务会自动revertversion.txt的提交并删除已推送的 tag保证失败不会留下半成品版本号。工作流最后还会根据输入自动触发后续分发docker-push构建 Docker 镜像daily参数取pre-release值call-cloudsmith-publish在pre-releasefalse时调用 Cloudsmith 发布详见后文。清单在此时有一句轻松但重要的提示Take a sip of tea ☕, bask in the glory of automation.——一旦点下 Run Workflow版本号、tag、各平台安装包与 GitHub Release 均由自动化完成这也是该仓库刻意设计的无人值守体验。第 3 步触发 quarto.org 官网下载页更新新稳定版可用后需要同步 quarto.org 官网。清单要求在 quarto-dev 组织下的quarto-web仓库中运行其 Update Downloadsupdate-downloads.yml工作流分支选择main。该工作流会自动检测新 release并更新 quarto-web 中的下载页文件使官网下载链接指向新版本。清单特别提示趁官网自动化运行的间隙同步推进下一步的 PyPI 发布——两条分发链路互不阻塞可以并行操作。第 4 步发布 Python 包到 PyPI官网更新期间需要在 quarto-cli-pypi 仓库PyPI 发布专用的下游仓库完成 Python 包发布在 quarto-cli-pypi 仓库中更新version.txt为要发布的版本号并提交进入 Actions选择 Publish Quarto PyPi 工作流点击 Run Workflow通过Production Release选项控制发布目标发布测试推荐先行取消勾选Production Release发布到 test.pypi。完成后用以下命令验证清单提醒首次执行可能因包未同步而提示找不到触发缓存失效后第二次通常成功python3 -m pip install -i https://test.pypi.org/simple --extra-index-url https://pypi.org/simple quarto-cli发布生产勾选Production Release正式发布到 PyPI。发布完成后同样Take a sip of tea ☕, bask in the glory of automation.第 5 步推送 chocolatey 包前提条件必须等 quarto.org 下载页已更新为新版本后才能执行 Chocolatey 发布——否则下载页与包源不一致会导致用户装到旧版本。步骤为在 quarto-dev 组织的quarto-release-bundles仓库中打开 Build Choco package Publish 工作流点击 Run Workflow务必勾选Whether to publish or not the package on chocolatey复选框等待维护者收到邮件确认即可无需其他操作。第 6 步整理稳定版 changelogbackports 归位这是收尾步骤也是唯一涉及直接修改本仓库代码的步骤。在 news/changelog-1.x.md当前仓库中即news/changelog-1.11.md中将# v1.(x1) backports标题下的## In this release中的条目整体移动到## In previous releases小节——因为本次补丁发布后这些 backport 已经正式随补丁版本上线提交并推送到稳定的v1.x分支commit message 中必须包含[release checklist]字样方便下个月判断是否需要再次发布补丁时快速检索历史。这套 changelog 结构的来源可以追溯到分支创建与 backport 流程在 checklist-make-a-new-quarto-release.md 中创建v1.x分支时要为news/changelog-1.x.md预先铺设# v1.(x1) backports含空的## In this release与## In previous releases子节此后由 checklist-backport-a-pr.md 流程把修复提交 backport 到稳定分支并登记到## In this release。本次稳定版发布正是这条链路闭环的时刻把已登记待发的条目降级为已随本补丁发布。其他渠道自动化与社区维护的分发除上述需人工操作的分发外稳定版发布还覆盖以下渠道多数为自动化或社区维护无需额外动作CloudsmithLinux 的 DEB/RPM 包由 Build Installers 工作流自动发布无需手动操作。源码层面create-release.yml 的call-cloudsmith-publish任务条件为inputs.publish-release !(inputs.pre-release true)——即稳定版pre-releasefalse自动触发prerelease 则跳过。手动重发场景见 cloudsmith-publishing.md其中也说明了首个 stable 版本因由预发布构建重标记而来Cloudsmith 不会自动获得它需要手动发布一次conda-forge自动创建 PR 更新quarto-feedstock中的包版本社区维护仓库成员作为 PR 审阅者仅在 PR 出问题时介入Wingetwinget bot 自动向 microsoft/winget-pkgs 提交 PR社区维护无需动作Scoop自动更新 manifests 仓库中的清单为维护者个人维护项目无需动作Homebrewhomebrew bot 自动更新 homebrew-cask 中的quartocask 清单无需动作。源码视角一次补丁版本号是如何计算与落盘的最后从源码角度把构建安装程序这一步的内部逻辑看透。create-release.yml的 configure 任务是整个发布的核心调度器其版本计算逻辑对应 create-release.yml 中 Get previous version 步骤如下read_version$(cat version.txt) version$(echo $read_version | grep -o [[:digit:]]*\.[[:digit:]]* | head -1) if [ $version $QUARTO_VERSION ]; then # 补丁发布build_number 1 build_number$(($(echo $read_version | grep -o [[:digit:]]* | tail -1)1)) else # 新 major/minorbuild_number 归零并确保 changelog 文件存在 version$QUARTO_VERSION build_number0 fi version_full$version.$build_number即当version.txt如1.11.5的主次版本与configuration中QUARTO_VERSION1.11一致时本次构建就是1.11.6否则视为进入新周期build_number 重置为 0。随后工作流把version_full写入version.txt、提交并打v1.11.6tagrelease note 自动生成v1.11.5...v1.11.6的 compare 链接与 changelog 下载链接。所有平台产物构建完成后发布任务生成quarto-1.11.6-checksums.txt并在 GitHub Release 上附带全部 12 类产物源码 tarball、Linux tarball/deb/rpm 双架构、Windows MSI/zip、macOS pkg/tar.gz、changelog、checksums。这一套读版本 → 算版本 → 打 tag → 构建 → 校验 → 发布 → 失败回滚的闭环正是稳定版补丁能够以近乎一键方式落地的底层原因而清单要做的就是把自动化链条之外的三件事盯住测试分支选对、Pre-release 与 Publish release 两个开关设对、发布顺序官网 → Chocolatey不颠倒。小结稳定版发布速查步骤动作关键参数 / 约束1. 测试Parallel Smokes Tests分支选v1.x稳定分支2. 构建Build Installerspre-release取消勾选publish-release勾选分支选v1.x3. 官网quarto-web 的 update-downloads 工作流在main分支运行4. PyPIquarto-cli-pypi 的 Publish Quarto PyPi可先取消Production Release发布到 test.pypi 验证5. Chocolateyquarto-release-bundles 的 Build Choco package Publish必须等官网下载页更新后勾选发布复选框6. Changelog移动 backports 条目到## In previous releasescommit message 含[release checklist]推送到v1.x7. 其余渠道Cloudsmith / conda-forge / Winget / Scoop / Homebrew自动化或社区维护一般无需动作整个流程中人工操作的失败风险集中在分支与开关设置上版本号计算、安装包构建、GitHub Release、Docker 镜像、Cloudsmith 分发均由 create-release.yml 及其协作工作流自动完成——理解这套自动化边界就能在几分钟内安全地完成一次 Quarto 稳定版补丁发布。赞分享开发工具文档【免费下载链接】quarto-cliOpen-source scientific and technical publishing system built on Pandoc.项目地址https://gitcode.com/gh_mirrors/qu/quarto-cli点击查看免费下载相关推荐VisiData 稳定版发布全流程指南从分支合并、版本号同步到 PyPI 与多发行渠道分发VisiData 稳定版发布全流程指南从分支合并、版本号同步到 PyPI 与多发行渠道分发 本文是 VisiData 项目内部发布检查清单 dev/chec数据分析CLI数据可视化Quarto 版本发布全流程指南从分支切分到多渠道分发的完整发布清单Quarto 版本发布全流程指南从分支切分到多渠道分发的完整发布清单 Quarto 是一个构建在 Pandoc 之上的开源科学与技术出版系统参见仓库根目录开发工具文档Falcon 发布全流程指南从版本号到稳定分支的 Release Manager 实操手册Falcon 发布全流程指南从版本号到稳定分支的 Release Manager 实操手册 导读 本文以 Falcon 仓库中的 RELEASE.md htt后端Web框架API设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考