17

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

我试着画一些东西,比如:

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

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

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

4

2 回答 2

9

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

给定xyz

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

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

  • z = 每次修复错误时增加。如果xy增加,则重置此数字。


注意:就个人而言,我喜欢认为,如果您将y输入两位数,是时候考虑重新设计用户界面,这将导致x增加。

于 2014-03-06T03:20:49.290 回答
2

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

于 2014-01-24T17:14:52.097 回答