mcpField
S
semver

semver

github.com/lelborn开发050 次安装2 周前更新
代码仓库

关于 semver

semver 是一项应用 Semantic Versioning 2.0.0 的参考技能，说明如何界定公开 API、分类变更、选择版本增量，并校验或比较版本字符串。

主要功能

  1. 01Major、Minor、Patch 决策规则
  2. 021.0 前版本处理指南
  3. 03版本字符串校验
  4. 04版本优先级比较
  5. 05供工作流使用的精简输出格式

适用场景

  1. 01根据变更集选择发布版本增量
  2. 02校验版本字符串
  3. 03比较预发布版本

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/lelborn/skills --skill semver

安装后在 Claude Code 中输入/semver确认已加载。

详细介绍

语义化版本控制（SemVer 2.0.0）

SemVer 2.0.0 的决策逻辑与参考。其他工作流（keep-a-changelog 和 conventional-commits 技能）经常会使用它，只需要升级幅度和原因，因此回答应简洁。

版本是对已声明的公共 API的兼容性承诺：MAJOR = 会造成破坏，MINOR = 新增但兼容，PATCH = 兼容性修复。若未声明公共 API，“破坏性”就无从定义——应先明确 API，或在决定前询问。

格式

MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]
  • MAJOR.MINOR.PATCH：非负整数，不带前导零（1.9.0）。
  • 预发布版本位于 - 之后（1.0.0-alpha.1）；构建元数据位于 + 之后（1.0.0+20130313144700）。
  • 预发布版本和构建元数据标识符：由 [0-9A-Za-z-] 组成，以点分隔，不能为空；数字预发布版本标识符不能带前导零。

决定升级幅度

不要仅按“有新内容 = MINOR”来判断。分三步推理：

  1. 明确公共 API。 只有针对使用者所依赖的已声明接口，版本才有意义——例如库的导出项、CLI 标志、HTTP 契约，或仓库中可安装技能的集合。未声明接口 → 先明确接口或询问；没有接口，“破坏性”就无从定义。
  2. 根据每项变更对该接口的影响进行分类，而不是看差异的大小：它会_破坏_现有用法、_新增_兼容能力，还是_修复_现有契约内的行为？全新且需选择启用的单元——例如新技能、新子命令——属于新增，不属于破坏性变更：不会改变任何人现有的用法。
  3. 确定对应的版本位，并留意主版本为零时的变化，因为每个数字所代表的承诺取决于是否已发布 1.0.0。

1.0.0 及以上——公共 API 是一项承诺。按顺序匹配，符合第一项即采用：

  1. 任何不向后兼容的变更 → MAJOR（MINOR 和 PATCH 重置为 0）。
  2. 新增向后兼容的功能，或弃用某项功能 → MINOR（PATCH 重置为 0）。
  3. 仅有向后兼容的修复 → PATCH。

低于 0.y.z——仍处于初始开发阶段，尚未发布 1.0.0，因此没有兼容性承诺；数字表示的是_相对_风险。版本位整体下移一位，与 ^ 范围的解析方式一致（^0.1.0 表示 >=0.1.0 <0.2.0，因此 MINOR 是发生破坏性变更的位置）：

  1. 不向后兼容的变更 → MINOR（0.3.2 → 0.4.0，PATCH 重置为 0）。
  2. 任何兼容性变更——功能或修复 → PATCH（0.3.2 → 0.3.3）。

因此，向 0.1.0 仓库添加新技能属于 PATCH → 0.1.1，而非 MINOR。务必说明 0.x 版本不提供稳定性保证，并在 API 稳定且投入生产后发布 1.0.0。

包含多种变更时，由影响最大的变更决定版本——只要有一项破坏性变更，就决定了升级级别。

验证版本字符串

官方正则表达式：

^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

分组：1=主版本，2=次版本，3=修订版本，4=预发布版本，5=构建元数据。标记以下问题：前导零（01.2.3）；以 v 开头（v1.2.3——这是标签前缀，验证前先去除）；少于三个部分（1.2）；预发布版本或构建元数据标识符为空（1.0.0-）。

比较优先级

  1. 依次按数值比较 MAJOR、MINOR、PATCH；第一个不同的部分决定优先级。
  2. 核心版本相同：带有预发布版本的版本低于不带预发布版本的版本（1.0.0-alpha < 1.0.0）。
  3. 两者都有预发布版本：从左到右比较标识符——两者均为数字时按数值比较；否则按 ASCII 顺序比较；数字标识符低于字母数字标识符；若所有共有标识符都相同，标识符更多的版本优先级更高。
  4. 构建元数据不影响优先级。

从低到高：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

边界情况

  • **以次版本／补丁版本发布破坏性更改：**不要修改已发布的版本——先发布一个恢复兼容性的补丁版本，然后在 MAJOR 版本中正式引入破坏性更改。
  • **仅升级依赖项：**如果是修复错误，则提升 PATCH 版本；如果是为了启用你所公开的新功能，则提升 MINOR 版本。
  • **弃用：**提升 MINOR 版本，记录相关说明，并至少保留到下一个次版本发布后，再在 MAJOR 版本中移除。
  • 已发布的版本不可变——更正内容应通过新版本发布。
  • **0.0.z：**主版本为零时没有兼容版本可用（^0.0.3 不允许任何版本）——将每项更改都视为可能存在破坏性，提升 PATCH 版本，并保留不稳定性警告。

为另一工作流生成精简输出

current: 0.3.2
bump: patch
next: 0.3.3
reason: added an opt-in --dry-run flag; no existing behaviour changes
warning: pre-1.0 (0.y.z) — no compatibility promise; minor is the breaking slot

仅当输入版本无效或版本处于 0.y.z 时，才添加 warning: 行。对于此处未涵盖的内容（BNF 语法、完整 FAQ），请阅读 semver.org。

评论

支持 Markdown