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