对于非API软件，是否存在等效的语义版本控制方案？

Question

我非常喜欢语义版本控制方案，但它实际上只对API有意义，因为重点是打破更改和向后兼容性。对于非API，例如最终用户软件，许多规则不再有意义。例如，向后兼容的概念并不意味着什么;用户体验新功能，或者他们没有，更少的错误或他们没有，等等。然而，我会受益于一个明确的xyz版本化方案，遵循语义版本控制的精神，以便用户可以有一些想法会有什么期望如果他们熟悉该计划，请从新版本编号开始。

我尝试草绘诸如以下内容：

• 如果对代码进行内部更改（例如错误修复，重构）而不改变用户体验，则会使用zump z。可能包含新的“内部”功能。
• 如果添加的功能可以将用户体验更改为当前功能的错误修复。
• 颠簸x ...... ???用户体验发生了根本不同的变化？什么是截然不同的？
• 初始alpha开发以0.0.z
发生
• 首次beta测试版本设置为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 递增，请重置此数字。

• z =每当您修复错误时都会增加。如果 x 或 y 递增，请重置此数字。

注意：就个人而言，我认为如果你将 y 纳入两位数字，那么就该考虑重新设计用户界面会导致增加 x 。

Answer 2

如果您的软件保存数据文件或读取配置文件，那么这些文件的格式至少是您的“API”，因此该格式的更改原则上可以证明碰撞X.