我目前在公司的官僚地狱中，需要定义对我们的测试程序进行不同级别的软件更改的构成。我们有一个内部遵循的粗略做法，但我正在寻找一个标准（如果存在）以在我们的质量体系中参考。我认识到开发人员之间的系统可能会有很大差异，但最终我正在寻找一个“最佳实践”指南，说明什么是重大变化、微小变化等。我想在提交给我们的质量系统时参考一个已发布的文档如果可能，ISO 目的。
澄清我公司开发的软件在内部用于半导体的测试自动化。我们不出售此代码，版本控制实际上仅用于记录保存。我们正在使用 xyz 更改来影响发布所需的签核和批准级别。
一个好的做法是使用 3 级修订号：
xyz
x 是主要的 y 是次要的 z 是错误修复
重要的是具有相同 x 的两个不同软件版本应该具有二进制兼容性。ay 大于另一个的软件版本，但相同的 x 可能会添加功能，但不会删除任何功能。这确保了在同一主要号码内的可移植性。最后 z 不应该改变任何功能行为，除了错误修复。
编辑：
以下是一些使用的修订号方案的链接：
我会将内部版本号添加到 xyz 格式：
xyzbuild
x = 主要功能更改
y = 次要功能更改
z = 仅修复错误
build = 每次编译代码时递增
包括内部版本号对于人们试图弄清楚他们拥有的二进制文件中是否存在特定更改的内部目的至关重要。
要放大@lewap 所说的内容，请使用
xyz
其中 z 级别的更改几乎完全是错误修复，不会更改接口或涉及外部系统
其中 y 级别更改添加功能并可能更改 UI/API 接口，此外还修复可能涉及外部系统的更严重的错误
其中 x 级别更改涉及从完全重写/重新设计到仅更改数据库结构到更改数据库（即从 Oracle 到 SQLServer）的任何事情 - 换句话说，任何不是需要“端口”或“转换”的更改的下降“ 过程
正如我之前在回答类似问题时所说：使用的术语不是很精确。有一篇文章描述了五个相关维度。用于软件开发的数据管理工具往往不会同时一致地支持三个以上的工具。如果你想支持所有五个，你必须描述一个开发过程：
Peter van den Hamer 和 Kees Lepoeter (1996) 管理设计数据：CAD 框架、配置管理和产品数据管理的五个维度，IEEE 会议记录，卷。84，第1号，1996年1月
我认为，如果您正在开发内部软件与外部软件（产品），它可能会有所不同。
对于内部软件，使用正式定义的方案几乎永远不会成为问题。然而，对于产品而言，版本或发布号在大多数情况下是不反映任何技术或功能标准的商业决策。
在我们公司，xyz 编号方案中的 xy 由营销男孩和女孩确定。z 和内部版本号由研发部门确定，并追溯到我们的修订控制系统，并与生成它的 sprint 相关（sprint 是迭代的 Scrum 术语）。
此外，正式定义版本和发行版之间的某种程度的兼容性可能会导致您非常快速地升级或几乎不升级。这可能不会反映添加的功能。
我认为让您向您的同事解释这一点的最佳方法是通过从知名和成功的软件包中提取的示例，以及它们处理主要和次要版本的方式。
我要说的第一件事是，用于发布的major.minor 点表示法是一项相对较新的发明。例如，大多数 UNIX 版本实际上都有名称（有时包括一个无意义的数字）而不是版本号。
但是假设您要使用major.minor 编号，那么主编号表示的版本基本上与以前的许多版本不兼容。考虑从 Windows 2,0 到 3.0 的变化 - 大多数 2,0 应用程序根本不适合 Windows 3,0 中新的重叠窗口。对于不那么包罗万象的应用程序，文件格式的根本变化（例如）可能是主要版本更改的原因 - WP &n 图形应用程序通常以这种方式工作。
主要版本号更改的另一个原因是用户注意到了差异。从 Windows 2.0 到 3.0 的变化再一次如此，并为后者的成功负责。如果您的应用程序看起来非常不同，那是一个重大变化。
A 表示次要版本号，这通常用于表示实际上非常主要的 chanhe，但用户不会注意到。例如，Win 3.0 和 Win 3.1 的内部差异实际上是相当大的，但界面保持不变。
关于第三个版本号，很少有人知道它的真正含义和更少的关心。例如，在我的日常工作中，我使用 GNU C++ 编译器版本 3.4.5 - 这与 3.4.4 有什么不同 - 我不知道！