将版本留在 API 中时有什么优点和缺点？答案

【问题标题】：Any Pros and Cons when leaving versions inside APIs?将版本留在 API 中时有什么优点和缺点？
【发布时间】：2014-01-17 02:23:35
【问题描述】：

考虑到这一点，我们有一组 API 即将发布，并且很可能在未来自下而上重新设计，将版本控制保留在包级别以实现向后兼容性，以便用户始终可以获得最新的发布而不用担心破坏他们的代码比发布不同的库版本更好，如果用户不坚持某个发布的版本，向后兼容性并不总是得到保证？

例如MyClass-LATEST.jar，其中有package MyClass.v1;，然后在将来提供package MyClass.v2;，同时将MyClass.v1 保留在同一个库中 MyClass-LATEST.jar 反对发布 MyClass-vX.X-RELEASE.jar...

干杯

【问题讨论】：

标签： java versioning release-management

【解决方案1】：

我不会将版本号放在 API 中。如果您发布的版本不向后兼容，则用户无需升级。但是如果你让一个版本向后兼容，比如一个错误修复版本，你将强制用户更改他们的包名，而不仅仅是能够放入一个新的 jar。

构建工具（ant、maven、gradle 等）用于管理版本。您不需要在 API 包名称中这样做。

【讨论】：

谢谢，但我不是这个意思。肯定会有错误修复并保留在相同的 API 中。但是 v1, v2, ... 会从根本上有所不同。当然，LATEST 也可以包含旧版本的错误修复。
但是如果您有 v1.1 或 v1.2 怎么办？无论哪种情况，您认为将 API 版本放在包名中有什么好处？
嗯，编号可能会让人感到困惑。假设它的 MyClass.lite;后来在 MyClass.nextgen;... 类似的东西
我不会像那样在你的类名中使用限定符。它使类名更加混乱。如果我想使用你的 MyClass 的 API，如果我需要知道它是 MyClass.lite、MyClass.nextgen 等，那真是太痛苦了。这也使开发变得更加困难，例如将更改从 MyClass.v1 合并到 MyClass.v2 ，现在是不同的文件。保持简单。
好吧，所以我知道人们受过培训，可以接受 v2.0-RELEASE 在这个意义上可能与 v1.0-RELEASE 不兼容。