对于非 API 软件，是不是有与语义版本控制等效的方案？

Posted 2023-03-07

【中文标题】对于非 API 软件，是不是有与语义版本控制等效的方案？

【英文标题】：Is there an equivalent scheme to Semantic Versioning for non-API software?对于非 API 软件，是否有与语义版本控制等效的方案？

【发布时间】：2013-05-25 10:29:18

【问题描述】：

我真的很喜欢语义版本控制方案，但它真的只对 API 有意义，因为重点是突破性更改和向后兼容性。对于非 API，例如最终用户软件，许多规则不再有意义。例如，向后兼容的概念本身并没有任何意义。用户体验新功能或不体验，减少错误或不体验等。然而，我将从遵循语义版本控制精神的明确 xyz 版本控制方案中受益，以便用户可以对预期有所了解如果他们熟悉该方案，则从新版本号开始。

我试着画一些东西，比如：

如果对不改变用户体验的代码进行内部更改（例如错误修复、重构），则发生故障。可能包括新的“内部”功能。 如果添加的功能会改变用户体验，而不是对当前功能的错误修复，请点击 y。 Bump x...???...对用户体验有根本不同的改变？有什么根本不同？ 最初的 alpha 发展发生在 0.0.z 第一个 beta 测试版本设置为 0.1.0 并保持为 0.y.z 第一个用户版本设置为 1.0.0

另一个想法是当功能被删除时产生 x 颠簸，因为某些用户可能会依赖它们，但在某些情况下这似乎没有根据。 （假设您认识所有用户，他们都希望删除一个非常小的功能。从 1.0 升级到 2.0 有点违反直觉。）

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

【问题讨论】：

如您所见，语义版本控制不是关于管理代码的主观特性/营销质量，而是与客观兼容性有关。你为什么需要或想要这个？

【参考方案1】：

我自己一直在寻找类似的东西，但没有找到任何“官方”的东西。不过，这就是我最近的版本编号方式。

鉴于 x.y.z

x = 每次重新设计用户体验时增加。例如，您重新安排主界面上的内容，就像 Microsoft 对 Office 2003 与 2007 所做的方式一样。如果您的应用程序存储用户文件或设置，如果更改不能向后兼容旧的，则该数字也应该增加文件或设置。

y = 基本上每当您添加新的新子例程/函数时都会增加。通常，添加新菜单项或按钮之类的事情属于此类，因为您必须编写回调来处理菜单项或按钮上的单击事件。另一个例子是对代码的任何更改，这些更改不会对用户产生明显的影响，但会提高可管理性（例如，您终于开始编写一个类来管理您的设置文件）。如果 x 增加，则重置此数字。

z = 每次修复错误时增加。如果 x 或 y 增加，请重置此数字。

注意：就我个人而言，如果您将 y 输入两位数，是时候考虑重新设计了strong> 的用户界面，这将导致 x 的增量。

【讨论】：

对任何感兴趣的人的附注：我实际上有几个想要重写的项目。例如，我想将一些 VB.Net 应用程序转换为 C#，并且我有一个 ASP.Net Web Forms 应用程序我想将其更改为 MVC。我还没有决定是增加 x 还是 y 。

Drew - 重写意味着从 v1 恕我直言重新开始。那时它确实是一个新应用程序，即使它具有相同的功能。

嗨，就我而言，我确实通过添加更好的用户界面来增加新的用户体验。但是，就我而言，这个新的用户界面仅适用于付费版本（输入激活密钥时解锁）。未付费时，我仍然提供相同版本的旧用户界面.. 那该怎么办？改变 x 还是改变 y？

【参考方案2】：

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

【讨论】：

我喜欢这种看待它的方式，但我可以想象，如果您将全新的设置添加到配置文件中同时保留旧的设置，我只会增加 y。