提供版本号，以明确您何时破坏向后兼容性
我的开源项目已经工作了大约 6 个月，我想尽快正式发布它。问题是，我很确定在不久的将来我会想要以一种会破坏向后兼容性的方式更改我的项目，可能会多次。 （我的代码是一个框架，人们必须在其中根据特定的 API 构建代码。）
有什么好方法可以将该项目标记为处于向后兼容性可能很快就会被破坏的状态？
我发现有些项目，比如 Python 和 Django，有这样的规则：在共享相同“大版本号”的版本之间保持向后兼容性。 （即立即留下点的数字。）
我一直在考虑采用这个规则，但这有点奇怪，如果下周我发布版本0.1，然后我无法破坏向后兼容性，直到我发布版本1.
有什么想法吗？
I've been working on my open source project for about 6 months, and I want to release it officially soon. The thing is, I'm quite sure that in the near future I will want to change my project in a way that will break backward compatibility, probably multiple times. (My code is a framework in which people have to build code according to a certain API.)
What would be a good way to mark this project as being in a state where backwards-compatibility might be broken soon?
I see that some projects, like Python and Django, have the rule that backward compatibility is maintained between versions which share the same "big version number." (i.e. the number immediately left to the dot.)
I've been thinking to adopt this rule, but it would be kind of weird, if next week I release version 0.1, and then I couldn't break backward compatibility until I release version 1.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你把它搞反了。当您破坏向后兼容性时，而不是当您用完次要编号时，您可以增加主要编号。尽管在 0.x 版本中，您可能还会认为该软件太不成熟且不稳定，甚至懒得维护兼容性。
You got it backwards. You increase the major number when you break backwards compatibility, not when you run out of minor numbers. Though at 0.x you might also consider the software too immature and unstable to even bother maintaining compatibility.
为什么不继续发布版本 1。继续更新该版本而不破坏向后兼容性，然后单独发布版本 2。
不管怎样，每当我听到最终无法实现向后兼容性时，我都会感到畏缩，但这更多的是个人观点。
Why don't you go ahead and release version 1. Continue to update that version without breaking backwards compatibility, and then release version 2 separately which does so.
Either way, I cringe every time I hear backwards compatibility will not be met eventually, but that's more of a personal opinion.