Git仓库包名变更的Semantic Versioning指南及React组件重命名版本咨询

这确实是Semver没明确覆盖到的边缘场景，但社区已经形成了一套实用的处理方案，结合你的情况（功能完全向后兼容，但用户必须修改package.json的包名才能获取新功能），可以这样处理：

核心判断依据 #

Semver的核心是从用户的迁移成本出发：虽然你的组件功能没有破坏性变更，但用户必须主动修改依赖引用才能继续接收更新，这本质上是一种「依赖层面的不兼容变更」——因为旧包名将不再得到后续的功能迭代和维护支持。

具体策略 #

• 如果是将原有包直接重命名（旧包不再更新）：
  1. 给旧包发布最后一个patch版本，在这个版本中添加废弃（deprecated）提示，告知用户迁移到新包名，并在README里写清楚简单的迁移步骤。
  2. 新命名的包有两种版本选择：
     • 要是你想延续旧包的版本历史（比如旧包停在v3.2.1），可以直接把新包的初始版本设为v3.2.1，后续的功能迭代或bug修复再按Semver正常递增。
     • 更推荐的做法是把新包初始版本设为v1.0.0，明确标记这是一条全新的版本线，避免用户混淆旧包和新包的版本关联。
• 如果旧包仍会维护基础兼容，新包独立迭代新功能：
  这种情况下新包属于独立的包标识符，直接从v1.0.0起步即可，旧包继续按Semver维护patch/minor版本（只做兼容修复，不新增功能）。

为什么不选minor版本？ #

Minor版本是给「向后兼容的新功能」用的，用户不需要修改依赖引用就能拿到这些更新——但你的情况是用户必须改包名才能获取新功能，这不符合minor版本的定义，会让用户误以为旧包还能继续收到新功能更新，造成不必要的混淆。

内容的提问来源于stack exchange，提问作者Elliot Rodriguez