sbt-release 版本号管理完全指南把发版工作全部交给 version.sbt【免费下载链接】dubThe modern link attribution platform. Loved by world-class marketing teams like Framer, Perplexity, Superhuman, Twilio, Buffer and more.项目地址: https://gitcode.com/GitHub_Trending/du/dub做 Scala 项目发版最容易翻车的就是版本号管理。sbt-release 用根目录下一个 version.sbt 文件和一条 sbt release 命令解决这个问题升版本、打标签、发布、推送全部交给流水线自动完成。昨晚的翻车一个 -SNAPSHOT 引发的事故先讲个真实感很强的场景。周三晚上十一点你手动发布一个 Scala 服务把 build.sbt 里的2.3.1-SNAPSHOT改成2.3.1commit打标签v2.3.1执行发布。第二天早上同事炸了——下游项目拉到的正式依赖里混进了带-SNAPSHOT后缀的包而且仓库里的标签是v2.3.0少了个数字。排查半天发现发布完你忘了把版本号改回下一个开发版标签还打错了一位。手改版本号、手打标签、手动发布三步里错一步就是事故。这就是 sbt-release 想替你干掉的事。五分钟跑起来加一行插件sbt release 就能发在project/plugins.sbt里加这一行取最新版本号addSbtPlugin(com.github.sbt % sbt-release % 1.4.2)终端里敲sbt release。接下来是交互问答先问发哪个版本默认就是去掉-SNAPSHOT的当前版本再问下一个开发版叫什么默认加一后补-SNAPSHOT一路回车即可。跑完你会在项目根目录多出一个 version.sbt——它就是全文的主角下面细说。发布时的版本流转version.sbt 被流水线写了两次sbt-release 的默认发布流程releaseProcess一共十几个步骤但和版本号直接相关的核心动作是两次写入 version.sbt阶段动作说明1checkSnapshotDependencies检查是否混入 SNAPSHOT 依赖2inquireVersions交互确认发布版与下一个开发版给智能默认值3clean runTest清理并跑全部测试失败即中止4setReleaseVersion第一次写入version.sbt 变成2.3.15commitReleaseVersion提交这次改动6tagRelease打标签v2.3.17publishArtifacts发布制品到仓库8setNextVersion第二次写入version.sbt 变成2.3.2-SNAPSHOT9commitNextVersion再次提交10pushChanges推送提交与标签到远程注意发布动作卡在两次写入中间第一次写入让制品拿到正式版本号第二次把代码送回开发状态。发版 → 打标签 → 进入下一轮开发的循环一次流水线自动跑完你不用碰任何一行版本号。为什么 version.sbt 是独立文件三个设计细节它从不改你的构建定义。sbt 的构建定义本身就是 Scala 代码在 build.sbt 中间手改数字既不直观也容易出错。sbt-release 的做法是版本号单独放进 version.sbt写到哪里由设置项releaseVersionFile决定默认就是项目根目录源码中该逻辑定义在 ReleasePlugin.scala想换位置改一下配置即可。默认是构建级写法。version.sbt 的内容通常就一行ThisBuild / version : 2.3.1ThisBuild / version意味着整个多模块项目共享一个版本号——对绝大多数仓库来说这正是正确答案。想按模块单独管一个开关的事。把releaseUseGlobalVersion设为false写入的就会是项目级的version : 2.3.1各模块可以各走各的版本。还有个容易被忽略的好处version.sbt 就是普通 sbt 配置文件你用文本编辑器直接改sbt 立刻生效。临时要改个版本号又不想走完整发布流程时这是最快的路。六种版本升级策略对照表该加一哪一位怎么选下一个开发版本加一哪一位不用你自己想。sbt-release 从 0.8 版本起内置了六种 Bump 策略源码见 Version.scala策略行为示例什么时候用Major主版本号 11.2.3 → 2.0.0破坏性 API 变更Minor次版本号 11.2.3 → 1.3.0加新功能且向后兼容Bugfix修订号 11.2.3 → 1.2.4纯修复Nano第四位 11.2.3.4 → 1.2.3.5版本号超过三段的方案Next默认智能判断该加一哪一位1.0.0-RC1 → 1.0.0-RC2通用默认0.17 → 0.183.22.3.4.91 → 3.22.3.4.92NextStable同 Next但去掉预发布限定符1.0.0-RC1 → 1.0.0RC 收尾、正式转正默认策略 Next 足够聪明它会自动判断哪个数字该加一。想换策略时在 build.sbt 里写一行releaseVersionBump : sbtrelease.Version.Bump.Major即可其余不动。无人值守发布与自定义版本规则CI 里没人盯着怎么发三个参数按需取用sbt release with-defaults所有交互取默认值最适合 CI/CD 流水线sbt release skip-tests跳过测试适合凌晨两点的救火版本命令行直接钉死版本连问答都省了sbt release release-version 1.0.99 next-version 1.2.0-SNAPSHOT这条命令的含义本次发 1.0.99下一个开发版是 1.2.0-SNAPSHOT其余流程照跑。脚本化发布时非常好用。对默认推导不满意两个设置键随便覆写releaseVersion负责当前开发版 → 正式发布版的推导releaseNextVersion负责发布版 → 下一个开发版。它们都是普通的 sbt 设置键你可以用自己的函数整体替换默认逻辑。主版本逢十进一、按发布日期命名这类特殊规则覆写一下就能落地不用 fork 插件。避坑清单sbt 发布流程四个高频坑多模块被 ThisBuild 全库带飞你只想升一个子模块的版本结果所有模块版本号一起变了。想要各模块独立版本记得releaseUseGlobalVersion : false并单独管理。-SNAPSHOT 混进正式发布checkSnapshotDependencies查的是依赖里有没有 SNAPSHOT管不了你自己的版本号。交互时把默认值看仔细或直接用命令行参数钉死版本。git 标签打错tagRelease默认按v前缀格式打标签v2.3.1。手动补标签时格式对不上后续版本校验会报错排查半天才发现是前缀少写了。发布前忘记提交默认流程在两次写 version.sbt 后都会自动 commit如果你自定义了流程跳过了提交步骤标签会指在一个 version.sbt 还是旧号数的提交上之后想复现这个版本就无从查起了。今晚开始回车就好sbt-release 做的事情其实就一句话把版本号从散落在构建定义里的字符串变成独立、可读、可自动写入的文件再配一条默认就够用的发布流水线。版本号管理交给它你只负责回答发不发。去你自己的项目里加一行插件敲一下sbt release下一个版本就交给流水线吧。官方文档docs/official.mdAI功能源码plugins/ai/【免费下载链接】dubThe modern link attribution platform. Loved by world-class marketing teams like Framer, Perplexity, Superhuman, Twilio, Buffer and more.项目地址: https://gitcode.com/GitHub_Trending/du/dub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考