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

时间:2009-10-14 18:47:17

标签: versioning backwards-compatibility

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

将此项目标记为处于向后兼容性可能很快被破坏的状态的最佳方法是什么?

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

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

有什么想法吗?

2 个答案:

答案 0 :(得分:3)

你倒退了。当您向后兼容时,增加主要数字,而不是在您用完次要数字时。虽然在0.x时你也可能认为该软件太不成熟和不稳定甚至无法保持兼容性。

答案 1 :(得分:1)

为什么不继续发布版本1.继续更新该版本而不破坏向后兼容性,然后单独发布版本2,这样做。

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

相关问题