编程语言编译器【免费下载链接】purescriptA strongly-typed language that compiles to JavaScript项目地址https://gitcode.com/gh_mirrors/pu/purescript点击查看免费下载导读RELEASE_GUIDE.md 是 PureScript 编译器仓库面向**维护者maintainer**的官方发布手册完整定义了从发布前检查、版本号提升、发布候选RC构建到 GitHub / Hackage / npm 三端正式发布以及发布后生态联动的标准操作流程SOP。读完本文你将掌握如何为 PureScript 编译器打一个版本、purescript.cabal与npm-package/package.json之间的版本同步规则、如何借助update-changelog.hs自动化生成 CHANGELOG、如何利用 CI 自动发布预编译二进制与 npm 包以及发布后需要联动更新的下游项目清单。本文以该手册为骨架并结合仓库内实际源码与 CI 配置进行逐环节印证。一、发布前置条件账号与工具链发布 PureScript 编译器需要两个渠道的发布权限和一套本机工具链。原文列的四个前提逐条说明如下前提说明Hackage 账号需拥有purescript包在 Hackage 上的 maintainer 权限没有账号时需先注册并申请被邀请为维护者NPM 账号需拥有purescript包在 NPM 上的 maintainer 权限spago本机必须安装 spago用于发布前编译最新 package set 以验证兼容性npm 登录状态本机需已登录 NPM可通过npm whoami打印出账号用户名来确认其中“spago”在前置检查中承担关键作用它用于拉取并编译最新 package set见下文以确认新版本不会引入意外的破坏性变更。二、发布前的检查清单正式发布前维护者需要依次完成以下检查全部通过才可进入版本号提升阶段。2.1 编译最新 package set 验证无意外破坏这是发布前最重要的一步用将要发布的编译器当前工作树构建产物去编译社区最新的 package set确认没有意外的破坏性变更。原文给出的完整命令序列如下stack build mkdir wPackageSet pushd wPackageSet spago init spago upgrade-set # install all packages in the set spago install $(spago ls packages | cut -f 1 -d | tr \n ) # Verify that code compiles and docs are properly created stack exec bash EOF spago build spago docs -S EOF popd # rm -rf wPackageSet关键点spago upgrade-set会将 package set 升级到最新版本通过spago ls packages列举全部包名配合cut/tr拼成一次性安装命令确保 package set 中所有包都被拉取在stack exec bash子 shell 中执行spago build与spago docs -S即同时验证编译与文档生成两条路径验证完毕后wPackageSet临时目录可删除原文用rm -rf日常操作可手动清理。事实上这段验证流程在仓库 CI 中也有对应的自动化实现.github/workflows/ci.yml中buildjob 会执行../ci/fix-home stack --haddock exec ../ci/build-package-set.sh.github/workflows/ci.yml在sdist-test目录里用刚构建出的编译器跑同一套 package set 验证并额外检查 Linux 产物中不存在libtinfo依赖.github/workflows/ci.yml。这说明“编译 package set”不是一次性手工动作而是被固化进发布 CI 的常态关卡。2.2 核对 INSTALL.md 与实际构建环境一致INSTALL.md 是面向用户的安装说明发布前必须逐项核对GHC 版本是否与当前使用的版本一致——以当前仓库为例INSTALL.md写明编译器基于 GHC 9.8.4 构建INSTALL.md而 purescript.cabal 与 CI 的 lint job 容器haskell:9.8.4.github/workflows/ci.yml保持一致支持的操作系统列表是否正确——需要对照 GHC 官方文档核对 GHC 9.8.4 支持哪些 OSINSTALL.md中特别注明 Windows Vista 之前版本、macOS 10.7 Lion 之前版本不受官方支持INSTALL.md非官方安装方式是否需要移除例如已无人维护的渠道从源码构建的指引是否仍然有效。仓库的 Makefile 提供了一组与文档对应的本地构建目标可用于验证源码构建路径make buildstack build、make run以 fast 模式构建并运行purs、make install安装到 stack 路径Makefile。2.3 重新生成 LICENSE发布前需要用make license-generator重新生成LICENSE文件。该目标的实现是license-generator: ## Update dependencies in LICENSE $(stack) ls dependencies purescript --flag purescript:RELEASE | stack license-generator/generate.hs LICENSEMakefile其原理在 license-generator/generate.hs 中有完整注释通过stack ls dependencies --flag purescript:RELEASE列出所有依赖再由generate.hs脚本逐个向 Hackage 查询各依赖的许可证信息拼装后覆写LICENSE若某个依赖查不到许可证则脚本会以非零状态退出并打印缺失列表license-generator/generate.hs。注意必须带上purescript:RELEASEflag使依赖清单与正式发布构建一致。2.4 评估破坏性变更的下游影响如果本次发布包含破坏性变更手册要求至少通知以下三类下游必要时先行更新它们Libraries库语言本身的破坏性变更往往要求相关库同步升级才能适配更新 core libraries核心库更新 contrib libraries社区贡献库更新 node bindingsNode 绑定更新 web bindingsWeb 绑定Tools工具编译器 CLI 若有任何变化以下工具可能需要同步更新spagopulppsc-packagepurs-loaderide pluginsIDE 插件JSON formatsJSON 格式以下 JSON 格式若有变化需要评估其影响面Corefn编译中间表示对应仓库 src/Language/PureScript/CoreFnIde protocolIDE 通信协议对应 psc-ide/PROTOCOL.mdpurs publish产出的 JSON——该格式直接影响 PursuitPureScript 文档检索站点的收录三、制作发布候选Release Candidate3.1 版本号提升的四个改动点提交一个“提升版本”的 commit需要同步修改四处版本信息且彼此必须一致purescript.cabal中的version字段——设为预期的最终发布版本号purescript.cabalapp/Version.hs中的prerelease字段——设为-rc.0app/Version.hsnpm-package/package.json中的version字段——设为上述两项的拼接例如 cabal 版本0.15.16 prerelease-rc.0即0.15.16-rc.0npm-package/package.json中postinstall脚本里要安装的版本——必须与version字段一致。关于版本结构的坑app/Version.hs头部注释给出了明确解释Cabal 本身不支持 prerelease 标识符为了不误导执行purs --version的用户仓库把 prerelease 标识符手工拼在Paths.version之后正式发布时把prerelease置空字符串即可app/Version.hs。当前的npm-package/package.json中postinstall写的是install-purescript --purs-ver0.15.16npm-package/package.json正对应 cabal 中的version: 0.15.16。3.2 RC 的自动发布机制合并提升版本的 PR 之后RC 会被自动发布到 GitHub 和 npm无需手工操作。机制细节可以从 CI 配置中得到印证buildjob 依据github.event_name release判断是否为正式发布.github/workflows/ci.yml并计算do-not-prerelease决定是否要跳过 prerelease 构建make-prereleasejob 在满足push事件且非正式发布时触发调用ncipollo/release-action以prerelease: true创建自动预览发布.github/workflows/ci.yml随后在npm-package目录下执行npm version --allow-same-version $BUILD_VERSION、用sed同步postinstall中的--purs-ver最后npm publish --tag next.github/workflows/ci.yml。后续构建会依次发布到-rc.1、-rc.2……直到正式发布。RC 阶段完成后需要验证可以通过npm i purescriptnext安装。四、正式发布Making a release4.1 正式发布前的验证开始手工发布流程前先测试上一个发布到purescriptnext的构建是否能在下游项目中正常工作——这是对 RC 质量的最终把关。4.2 再次提升版本正式发布同样需要一个“提升版本”的 commit改动点与 RC 相同但有两处差异app/Version.hs的prerelease字段要清空若之前发布过 RC其余三处cabal 版本、npm 版本、postinstall 版本同样保持同步。4.3 自动化生成 CHANGELOG运行stack update-changelog.hs该脚本会把 CHANGELOG.d 目录中的条目移动到CHANGELOG.md中带新版本号的小节。它的自动化能力来自 update-changelog.hs从CHANGELOG.d/读取未发布的条目文件按文件名前缀分组break破坏性变更、feat新特性、fix修复、int内部、misc杂项update-changelog.hs新版本号从哪里来脚本从npm-package/package.json的version字段读取——这就是为什么必须先更新 npm 版本再运行脚本update-changelog.hs 与 update-changelog.hs通过 GitHub API 查询每个条目对应 PR 的编号与作者自动附加(#1234 by author)后缀update-changelog.hs按 PR 合并顺序排序、按类型分组生成小节最后把CHANGELOG.md与相关条目文件git add/git rm到暂存区为发布 commit 做好准备update-changelog.hs。条目文件的命名规范在 CHANGELOG.d/README.md 中有完整定义文件名形如{PREFIX}_{SLUG}.md前缀取breaking/feature/fix/internalmisc为兜底内容首行必须是以*开头的列表项CHANGELOG.d/README.md。4.4 提交 PR 并创建 GitHub Release将以上 commit 提交 PR 并合并后在 GitHub 的 releases 页面创建 release粘贴发布说明创建 release 会同时生成 Git tag触发 CI 构建CI 完成后会把预编译的编译器二进制上传到该 release 上对应.github/workflows/ci.yml中 “Release only” 的gh release upload --clobber步骤.github/workflows/ci.yml若 CI 失败也可以本地构建二进制后手工上传到 release。4.5 发布到 Hackage 与 npmHackage在仓库根目录运行stack upload .。建议随后检查purescript包能否从 Hackage 正常安装。npm等待 GitHub releases 页面上所有预编译二进制就绪后进入npm-package目录执行npm publishnpm dist-tag add purescriptVERSION next其中VERSION形如v0.15.16验证npm i purescriptnext可安装验证npm i purescript可安装4.6 发布失败的兜底策略手册特别强调如果一次发布出了问题例如历史上的v0.14.3事件不要删除出问题的 GitHub release 或它的 Git tag。正确做法是发布一个新版本在出问题 release 的 GitHub 发布说明中以及CHANGELOG.md对应小节里注明这不是一个真正的发布在相应位置引导用户转向新版本。这一策略保证了 Git tag 历史的可追溯性避免破坏依赖旧 tag 的外部引用。五、发布后的生态联动清单正式发布完成后维护者还需完成以下收尾工作文档仓库记录任何语言层面的变更尤其要确认文档仓库的“快速上手”教程仍然可用Pursuit 重新部署若满足任一条件——Prim模块有任何改动即使只是文档改动、文档 JSON 格式有变化——则需要让 Pursuit 依赖最新版本并重新部署创建新的 package set为本次发布建立对应版本的新 package setTry PureScript 更新将 Try PureScript 更新到最新版本与最新 package set 并重新部署发布公告在 Discourse、Discord、Twitter、/r/purescript 四个渠道发布公告。其中第 2 条与文档 JSON 格式直接相关purs publish产出的 JSON 是 Pursuit 收录 PureScript 包文档的基础对应 app/Command/Publish.hs 与 src/Language/PureScript/Publish 的实现。六、发布流程全景一次发布的完整时间线综合全文一次 PureScript 编译器发布可归纳为以下时间线发布前检查编译 package set / 核对 INSTALL.md / 重生成 LICENSE / 评估下游影响 ↓ RC 阶段提升版本cabal Version.hs prerelease npm version postinstall ↓ 合并 PR → CI 自动发布 -rc.0 到 GitHub 与 npm--tag next ↓ 验证 npm i purescriptnext 正式发布再次提升版本prerelease 清空 ↓ 运行 stack update-changelog.hs 生成 CHANGELOG ↓ 提交 PR 并合并 ↓ 创建 GitHub Release生成 tag → CI 上传二进制 ↓ stack upload . 发布 Hackage ↓ npm publish dist-tag add ... next ↓ 发布后更新文档仓库 / Pursuit 重部署 / 新 package set / Try PureScript / 四渠道公告贯穿全程的两条铁律是版本号在 cabal、Version.hs、package.json、postinstall 四处必须严格同步发布失败不删 tag用新版本加更正说明替代。相关仓库文件索引RELEASE_GUIDE.md — 本文的原始依据维护者发布手册app/Version.hs —prerelease字段与purs --version版本字符串的组装逻辑purescript.cabal — cabal 包版本与RELEASEflag 定义npm-package/package.json — npm 包版本、postinstall脚本与二进制包装update-changelog.hs — CHANGELOG 自动化生成脚本从CHANGELOG.d/聚合条目CHANGELOG.d/README.md — changelog 条目文件的命名与写作规范Makefile —license-generator目标及常用构建/测试目标license-generator/generate.hs — LICENSE 重新生成脚本实现INSTALL.md — 发布前需核对的最新安装说明.github/workflows/ci.yml — 发布/预发布 CI 自动化二进制上传、npm publish --tag next赞分享编程语言编译器【免费下载链接】purescriptA strongly-typed language that compiles to JavaScript项目地址https://gitcode.com/gh_mirrors/pu/purescript点击查看免费下载相关推荐Creamplayer终极网易云音乐下载神器一键获取带内嵌歌词与封面的无损MP3Creamplayer终极网易云音乐下载神器一键获取带内嵌歌词与封面的无损MP3 Creamplayer是一款专为音乐爱好者打造的网易云音乐下载工具能够帮Rnote 维护者手册解读从翻译管线到 Flathub 发布的完整运维流程Rnote 维护者手册解读从翻译管线到 Flathub 发布的完整运维流程 Rnote 是一个用 Rust 与 GTK4 编写的开源矢量绘图与手写笔记应用桌面应用图形学npm 开发者指南从 package.json 到发布上线的完整实战手册npm 开发者指南从 package.json 到发布上线的完整实战手册 导读 本文是 npm 官方 developers Developer guide开发工具包管理器CLI上一篇HEIF Utility 上手3 步在 Windows 打开 iPhone 照片批量转 JPEG 也就几分钟下一篇HEIC 图片在 Windows 上打不开免费开源的 HEIF Utility 一分钟搞定创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考