语义版本控制如何应用于没有API的程序

在http://semver.org/（我认为这是版本控制中使用最广泛的约定）中，建议在引入破坏/修改API的更改时增加主版本号。

虽然有两种相关的情况，但我看不到如何应用此准则：

1. 如果我的代码不提供任何API怎么办？我应该如何版本代码？
2. 如果我的代码在开发的后期开始提供API，该怎么办？

Semver最关心的是版本库和软件包的版本，以避免各种形式的依赖地狱。但是，Semver背后的思想可以扩展到各种程序–任何一段代码都具有某种用户界面，或者这是毫无用处的。

• 编程库或Web服务具有API。
• 消费者软件可能具有GUI。
• 命令行程序具有一组开关和选项。
• 配置文件也是用户界面。

使用文字处理程序等消费类软件的示例：

• 当您发布错误修复时，增加补丁号，例如：“ 修复错误，其中应用程序总是在星期二00:00 PM崩溃 ”。
• 添加新功能时，增加次要版本号，例如：“ 增加了对带下划线的文本的支持 ”。
• 当您彻底检查用户界面或重写所有内部组件时，请增加主要版本。例如：“ 工具栏占用了过多的屏幕空间。现在仅通过触摸手势来提供UI ” –这样的更改将破坏现有的工作流程。

但是，Semver试图解决的许多问题并不存在于依赖项管理范围之外。在消费者应用程序中，版本不仅是版本，而且还是营销资产。

• Firefox和Chrome发行新版本的频率相对较高，并且在每次发行时都会增加其主要版本号。这导致高得离谱的版本号（目前都在30年代）。具有较高版本号的浏览器必须完全优于具有较低版本号的浏览器，对吗？

• Apple操作系统OS X的主版本号已成为名称的一部分（X在罗马数字中为10），使次版本号成为有效的主版本号。

• Ubuntu操作系统使用year.month.patchlevel版本控制方案。这使您很容易记住您的操作系统有多旧，但要弄清楚哪些版本是兼容的以及对每个版本的支持能持续多久则变得更加困难。

• Linux内核将版本号从2.6.39提升到了3.0.0，因为它的39尺寸变大了，以纪念Linux成立20周年。

• Donald Knuth富有传奇色彩的TeX排版系统使用的版本号从版本3开始，通过在每个发行版中添加另一个数字来收敛到π：3.14159265…。这表明系统如何越来越接近完美。同样，Metafont系统收敛于e：2.7182818…。

因此，Semver无法很好地服务于许多应用程序。选择一个对用户有利的版本控制方案（无论这些用户是程序员还是消费者），并保持一致。