1

我们正在开源一个以前专有的 Java 软件系统。我们松散地遵循了 Tom Preston-Werner 的语义版本控制，其中：

  • 错误修复意味着补丁更新（例如，1.0.X）
  • 对向后兼容的公共 API 的更改意味着较小的更新（例如 1.X.0）
  • 对向后不兼容的公共 API 的更改意味着重大更新（例如 X.0.0）

开源系统的任务需要我们重命名包。我们还认为我们应该整合以前存在的大部分模块。

重组任务不会改变公共 API，但会改变 API 用户的依赖关系。

重组/包重命名在哪里适合语义版本控制？在知名的开源项目中如何处理这样的重组？

4

1 回答 1

1

如果必须更改客户端代码以使用新版本，则这是不兼容的 API 更改。

于 2012-05-18T12:48:35.387 回答