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

Question

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

我试着草绘如下的东西:

• 如果对代码进行内部更改(例如错误修复,重构),则不会改变用户体验.可能包含新的"内部"功能.
• 如果添加的功能可以将用户体验更改为当前功能的错误修复.
• 颠簸x ...... ???用户体验发生了根本不同的变化？根本不同的是什么？
• 初始alpha开发发生为0.0.z
• 第一个beta测试版本设置为0.1.0并保持为0.yz
• 第一个用户版本设置为1.0.0

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

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

Answer 1

我一直在寻找类似的东西,但没有找到任何"官方"的东西.这是我最近在做版本编号的方式.

鉴于xyz

• x =每当您重新设计用户体验时都会增加.例如,您在主界面上重新排列内容,就像Microsoft使用Office 2003与2007版本一样.如果您的应用程序存储用户文件或设置,如果更改不会向后兼容,则此数字也应递增文件或设置.

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

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

注:就个人而言,我这样想,如果你Ÿ到双位数字,是时候考虑重新设计的用户界面,这将导致增量的X.

Answer 2

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