是否有一种与非API软件的语义版本控制等价的方案？

Question

我非常喜欢语义版本控制方案，但它确实只对API有意义，因为重点是打破更改和向后兼容性。对于非API，例如终端用户软件，许多规则不再有意义了。例如，向后兼容的概念本身并不意味着什么；用户经历了新的特性，或者没有，更少的bug，或者没有，等等。然而，我会从遵循语义版本控制精神的x.y.z版本控制方案中获益，这样用户就可以知道如果他们熟悉这个方案，可以从新的版本号中得到什么。

我试着画了一些草图，比如：

• 如果对不改变用户体验的代码(例如，bug修复、重构)进行内部更改，则会出现Bump z。可能包括新的“内部”功能。
• 如果添加将用户体验从错误修复更改到当前功能的特性，则会出现凸点。
• 碰撞x...???...radically不同的用户体验变化？什么是完全不同的？
• 最初的alpha开发发生在0.0.z
• 第一个测试版本设置为0.1.0，并保持为0.y.z
• 第一个用户发布设置为1.0.0

另一个想法是，当某些用户可能依赖这些特性时，删除这些特性时会出现x凸起，但在某些情况下，这似乎是不合理的。(假设您了解所有用户，他们都希望删除一个非常小的功能。从1.0到2.0可能有点违背直觉。)

这比语义版本更主观，因为客观地识别API的向后兼容特性和打破特性要容易得多。是否有任何“标准化”版本控制方案，我可以探索，以获得更多的指导？

Answer 1

我一直在寻找类似的东西，但没有找到任何“官员”。这是我最近怎么做我的版本编号。

给定x.y.z

• x =每当您重新设计用户体验时的增量。例如，您可以在主界面上重新安排一些事情，就像Microsoft对Office 2003和2007所做的那样。如果应用程序存储用户文件或设置，如果更改将与旧文件或设置不向后兼容，则此数字也应递增。
• 当您添加新的子例程/函数时，y =基本上增加。通常，添加一个新的菜单项或按钮就属于这个类别，因为您必须编写一个回调来处理菜单项或按钮上的单击事件。另一个例子是对代码的任何更改，这些更改不会对用户产生明显的影响，但会提高可管理性(例如，您终于有时间编写一个类来管理您的设置文件)。如果x递增，则重置此数字。
• 无论何时修复bug，z = Increment。如果x或y递增，则重置此数字。

备注:就我个人而言，我认为如果您将y输入到两位数字中，则是时候考虑用户界面的重新设计了，这将导致x__的增加。

Answer 2

如果您的软件保存数据文件或读取配置文件，那么这些文件的格式至少是您的"API“，因此，对该格式的更改原则上是合理的。