当您破坏向后兼容性时，提供明确的版本号答案

【问题标题】：Giving version numbers that make clear when you're breaking backward compatibility当您破坏向后兼容性时，提供明确的版本号
【发布时间】：2009-10-14 18:47:16
【问题描述】：

我的开源项目已经工作了大约 6 个月，我想尽快正式发布它。问题是，我很确定在不久的将来我会想要改变我的项目，以破坏向后兼容性的方式，可能会多次。（我的代码是一个框架，人们必须在其中根据某个 API 构建代码。）

将这个项目标记为处于向后兼容性可能很快被破坏的状态的好方法是什么？

我看到一些项目，如 Python 和 Django，有一个规则，即在共享相同“大版本号”的版本之间保持向后兼容性。（即紧挨着点的数字。）

我一直在考虑采用这条规则，但如果下周我发布 0.1 版，那会有点奇怪，然后在发布 1 版之前我无法打破向后兼容性。

有什么想法吗？

【问题讨论】：

标签： versioning backwards-compatibility

【解决方案1】：

你把它弄反了。当您破坏向后兼容性时，您会增加主要号码，而不是当您用完次要号码时。尽管在 0.x 中，您可能还会认为该软件太不成熟且不稳定，甚至无法维护兼容性。

【讨论】：

我考虑过制定一个 0.x 总是不兼容的规则，但我担心人们不会立即理解它，然后当他们的代码不起作用时他们会感到惊讶。
另外，您不能用完次要号码。版本号中的点不像逗号。在这种方案下，1.13.3 是一个完全合理的版本号。

【解决方案2】：

您为什么不继续发布第 1 版。继续更新该版本而不破坏向后兼容性，然后单独发布第 2 版。

无论哪种方式，每次我听到向后兼容性最终都不会得到满足时，我都会感到畏缩，但这更多是个人意见。

【讨论】：

我觉得发布版本 1 有点自命不凡，已经工作了 10 年的项目在版本 2-3 中。另外，我不想维护该软件的其他分支。我相信向后兼容性非常重要，但是当项目刚刚开始时，您需要时间来玩弄并探索没有这些手铐的可能性。