mcpField
V
versionbump

versionbump

本地服务
github.com/CloudCorpRecords开发工具01 周前更新

关于 versionbump

versionbump 是一个命令行工具和 MCP 服务,根据提交与公开 API 变更计算语义化版本升级。它按规则判断升级级别,并列出依据;计算在本地完成,输入错误会经过校验。

主要功能

  1. 01建议主版本、次版本、修订版或不升级
  2. 02分析提交与 API 变更
  3. 03按固定顺序列出依据
  4. 04严格校验语义化版本及输入
  5. 05提供本地命令行与 MCP 服务

适用场景

  1. 01确定下一次发布的版本号
  2. 02审查版本升级级别的判断依据

MCP 相关

向 MCP 客户端提供 recommend_version_bump 工具。工具接收当前版本、提交和可选的 API 变更,并返回下一版本、升级级别及原因。

配置

本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置
{
"mcpServers": {
"cloudcorprecords-versionbump": {
"command": "npx",
"args": [
"-y",
"@reneturcios/versionbump"
]
}
}
}
启动命令npx -y @reneturcios/versionbump

本地服务需要在你的电脑上安装运行环境(如 Node.js 18+)。各客户端的配置文件位置不同,请参考客户端文档。

安装包
npm@reneturcios/versionbump0.1.0
ocighcr.io/cloudcorprecords/versionbump:0.1.0

工具

1

收录的工具列表 · 更新于 1 周前

参数类型必填说明
commitsarray是自当前版本以来的提交(可以为空)
api_changesarray否自当前版本以来的公开 API 表面变更(省略可,默认值为 [])
current_versionstring是当前版本,严格遵循 MAJOR.MINOR.PATCH 语义化版本格式(例如 "1.4.2")

详细介绍

versionbump

选择下一个版本号通常依赖记忆来判断:“感觉应该是次要版本。” versionbump 将其变成计算过程。你只需提供当前版本、该版本之后的提交,以及该版本之后的公共 API 表面变更,它就会机械地应用语义化版本规则,然后列出选择该级别的依据,供任何人核查:

  • Major — 某个提交被标记为破坏性变更,或某个 API 条目被移除或发生不兼容变更。下一个版本为 (X+1).0.0。
  • Minor — 没有破坏性信号,但有 feat 提交,或新增了 API 条目。下一个版本为 X.(Y+1).0。
  • Patch — 没有破坏性或功能信号,但存在提交。下一个版本为 X.Y.(Z+1)。
  • None — 完全没有提交,也没有 API 变更。下一个版本保持当前版本不变。

按顺序匹配,首条匹配的规则优先;但依据会完整列出,而不只是列出胜出的规则:reasons 会按固定顺序列出每个破坏性提交、每项破坏性 API 变更、每个功能提交和每个新增 API 条目;每组内部按照输入顺序排列。Patch 升级会附带唯一一条原因:no breaking or feature signals; <n> commit(s) present;None 升级会附带 no commits and no API changes supplied。

功能检测采用精确匹配:只有类型恰好为 feat(区分大小写)的提交才算功能提交;其他所有提交类型都属于 Patch 级别,除非被标记为破坏性变更。当前版本必须是严格的 MAJOR.MINOR.PATCH 语义化版本,不得带预发布或构建后缀。格式错误的输入(例如无效的版本字符串、缺少类型的提交、包含未知类型的 API 变更)会触发校验错误,并指出出错路径(例如 commits[1].type must be a non-empty string);不会给出不完整的建议。计算是纯本地操作:不访问网络、不需要配置,也不会读取你传入的输入之外的文件。

CLI

npx @reneturcios/versionbump recommend --input args.json
npx @reneturcios/versionbump --version

args.json 包含完整的参数对象:

{
  "current_version": "1.4.2",
  "commits": [
    { "type": "feat" },
    { "type": "fix", "breaking": true }
  ],
  "api_changes": [
    { "kind": "added", "name": "exportReport" }
  ]
}

每个提交的 breaking 默认值为 false,api_changes 的默认值为 []。建议结果以 JSON 格式打印:

{
  "current_version": "1.4.2",
  "next_version": "2.0.0",
  "bump": "major",
  "reasons": [
    "commit[1] of type \"fix\" is marked breaking",
    "commit[0] is a feature (\"feat\")",
    "API entry \"exportReport\" was added"
  ]
}

退出代码:成功时为 0,发生运行时错误(包括输入文件无法读取或无效,或输入无效)时为 1,发生用法错误时为 2。

MCP 服务

npx -y @reneturcios/versionbump mcp

MCP 客户端配置:

{
  "mcpServers": {
    "versionbump": {
      "command": "npx",
      "args": ["-y", "@reneturcios/versionbump", "mcp"]
    }
  }
}
工具
  • recommend_version_bump — 根据提交类型和 API 表面变更建议下一个语义化版本,并列出所选升级级别的依据。

    • current_version(字符串,必需)— 严格的 MAJOR.MINOR.PATCH 语义化版本,例如 "1.4.2"
    • commits(数组,必需,可为空)— 由 {type, breaking?} 对象组成的提交列表;type 为 Conventional Commits 类型,breaking 默认值为 false
    • api_changes(数组,可选,默认值为 [])— 由 {kind, name} 对象组成的 API 变更列表,其中 kind 为 "removed"、"changed" 或 "added" 之一

    返回 {current_version, next_version, bump, reasons}。

Docker

docker run -i ghcr.io/cloudcorprecords/versionbump
docker run --rm -v "$PWD:/w" ghcr.io/cloudcorprecords/versionbump recommend --input /w/args.json

开发

npm install
npm run build   # tsc -> dist/
npm test        # tsx --test test/*.test.ts (pure local, no network)
npm run dev     # run the CLI from source

许可证

MIT — 版权所有 (c) 2026 Rene Turcios

评论

支持 Markdown

第一次接触 MCP?

从协议是什么,到在客户端里装上第一个服务,这几条回答覆盖了大多数入门问题。

一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。