版本（修订）变更的构成是否有标准定义
我目前在公司的官僚地狱中，需要定义什么构成了我们测试程序的不同级别的软件变更。 我们在内部遵循了一个粗略的做法，但我正在寻找一个标准（如果存在）在我们的质量体系中参考。 我认识到开发人员之间的系统可能会有很大差异，但最终我正在寻找一个“最佳实践”指南，以了解什么构成重大变更、较小变更等。我想在向我们的质量体系提交的文件中引用已发布的文档如果可能的话，采用 ISO 目的。
为了澄清我公司开发的软件在内部用于半导体的测试自动化。 我们不会出售此代码，版本控制实际上仅用于保存记录。 我们使用 xyz 更改来影响发布所需的签核和批准级别。
I am currently in bureaucratic hell at my company and need to define what constitutes the different levels of software change to our test programs. We have a rough practice that we follow internally, but I am looking for a standard (if it exists) to reference in our Quality system. I recognize that systems may vary greatly between developers, but ultimately I am looking for a "best practice" guide to what constitutes a major change, a minor change etc. I would like to reference a published doc in my submission to our quality system for ISO purposes if possible.
To clarify the software developed at my company is used internally for test automation of Semi-Conductors. We are not selling this code and versioning is really for record keeping only. We are using the x.y.z changes to effect the level of sign-off and approval needed for release.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
一个好的做法是使用 3 级修订号：
xyz
x 是主要版本号
y 是小数
z 是错误修复
重要的是具有相同 x 的两个不同软件版本应该具有二进制兼容性。 y 大于另一个的软件版本，但相同的 x 可能会添加功能，但不会删除任何功能。 这确保了同一主号码内的可移植性。 最后，除了错误修复之外，z 不应更改任何功能行为。
编辑：
以下是一些使用的修订号方案的链接：
A good practice is to use 3 level revision numbers:
x.y.z
x is the major
y is the minor
z are bug fixes
The important thing is that two different software versions with the same x should have binary compatibility. A software version with a y greater than another, but the same x may add features, but not remove any. This ensures portability within the same major number. And finally z should not change any functional behavior except for bug fixes.
Edit:
Here are some links to used revision-number schemes:
我会将内部版本号添加到 xyz 格式：
xyzbuild
x = 主要功能更改
y = 次要功能更改
z = 仅修复错误
build = 每次编译代码时递增
包含内部版本号对于内部目的至关重要，因为人们试图确定他们拥有的二进制文件中是否存在特定的更改。
I would add build number to the x.y.z format:
x.y.z.build
x = major feature change
y = minor feature change
z = bug fixes only
build = incremented every time the code is compiled
Including the build number is crucial for internal purposes where people are trying to figure out whether or not a particular change is in the binaries that they have.
为了放大@lewap所说的内容，请使用
xyz
，其中z级别的更改几乎完全是错误修复，不会更改接口或涉及外部系统，
其中y级别的更改除了修复更严重的错误之外还添加了功能，并且可能会更改UI/API接口这可能涉及外部系统
，其中 x 级别的更改涉及从完全重写/重新设计到仅更改数据库结构再到更改数据库（即从 Oracle 到 SQLServer）的任何内容 - 换句话说，任何不是需要“的更改下降”的内容端口”或“转换”过程
to enlarge on what @lewap said, use
x.y.z
where z level changes are almost entirely bug fixes that don't change interfaces or involve external systems
where y level changes add functionality and may change the UI/API interface in addition to fixing more serious bugs that may involve external systems
where x level changes involve anything from a complete rewrite/redesign to just changing the database structures to changing databases (i.e. from Oracle to SQLServer) - in other words anything that isn't a drop in change that requires a "port" or "conversion" process
我认为如果您正在开发内部软件与外部软件（产品），情况可能会有所不同。
对于内部软件来说，使用正式定义的方案几乎永远不会成为问题。 然而，对于产品来说，版本或发行号在大多数情况下是商业决定，不反映任何技术或功能标准。
在我们公司，xyz 编号方案中的 xy 由营销人员确定。 z 和内部版本号由研发部门确定，并追溯到我们的修订控制系统，并与其生成的 sprint 相关（sprint 是迭代的 Scrum 术语）。
此外，正式定义版本和发布之间的某种程度的兼容性可能会导致您非常快速地升级或几乎根本无法升级。 这可能不反映附加功能。
I think it might differ if you are working on an internal software vs a external software (a product).
For internal software it will almost never be a problem to use a formally defined scheme. However for a product the version or release number is in most cases a commercial decision that does not reflect any technical or functional criteria.
In our company the x.y in an x.y.z numbering scheme is determined by the marketing boys and girls. The z and the internal build number are determined by the R&D department and track back into our revision control system and are related to the sprint in which it was produced (sprint is the Scrum term for an iteration).
In addition formally defining some level of compatability between versions and releases could cause you to very rapidly move up or to hardly move at all. This might not reflect added functionality.
我认为，向同事解释这一点的最佳方法是从众所周知的成功软件包中提取示例，以及它们处理主要和次要版本的方式。
我要说的第一件事是，版本的主要.次要点表示法是一个相对较新的发明。 例如，大多数 UNIX 版本实际上都有名称（有时包括无意义的数字）而不是版本号。
但假设您想使用major.minor 编号，那么主编号表示的版本基本上与之前的版本不兼容。 考虑一下从 Windows 2.0 到 3.0 的变化 - 大多数 2.0 应用程序根本不适合 Windows 3.0 中新的重叠窗口。 对于不太全面的应用程序，文件格式的根本变化（例如）可能是主要版本更改的原因 - WP 和图形应用程序通常以这种方式工作。
主要版本号更改的另一个原因是用户注意到差异。 从 Windows 2.0 到 3.0 的转变也是如此，也是后者成功的原因。 如果您的应用程序看起来非常不同，那就是重大变化。
A 表示次版本号，通常用于指示实际上相当主要的 chanhe，但用户不会注意到。 例如，Win 3.0和Win 3.1之间的内部差异实际上相当大，但界面保持不变。
关于第三个版本号，很少有人知道它的真正含义，也很少有人关心。 例如，在我的日常工作中，我使用 GNU C++ 编译器版本 3.4.5 - 这与 3.4.4 有什么不同 - 我不知道！
I think that best approach for you to take hen explaining this to your co-workers is by examples drawn from well known and succesful software packages, and the way they approach major and minor releases.
The first thing I would say is that the major.minor dot notation for releases is a relatively recent invention. For example, most releases of UNIX actually had names (which sometimes included a meaningless number) rather than version numbers.
But assuming you want to use major.minor, numbering, then the major number indicates a version that is basically incompatible with much that went before. Consider the change from Windows 2,0 to 3.0 - most 2,0 applications simply didn't fit in with the new overlapped windows in Windows 3,0. For less all-encompassing apps, a radical change in file formats (for example) could be a reason for a major version change - WP &n graphic apps often work this way.
The other reason for a major version number change is that the user notices a difference. Once again this was true for the change from Windows 2.0 to 3.0 and was responsible forv the latters success. If your app looks very different, that;s a major change.
A for the minor version number, this is typically used to indicate a chanhe that actually is quite major, but that won't be noticeable to the user. For example, the differences internally between Win 3.0 and Win 3.1 were actually quite major, but the interface stayed the same.
Regarding the third version number, well few people know hat it really means and fewer care. For example, in my everyday work I use the GNU C++ compiler version 3.4.5 - how does this differ from 3.4.4 - I haven't a clue!
正如我之前在回答类似问题时所说：使用的术语不是很精确。 有一篇文章描述了五个相关维度。 用于软件开发的数据管理工具往往不会同时一致地支持其中三个以上。 如果您想支持所有五个，则必须描述开发过程：
Peter van den Hamer 和 Kees Lepoeter (1996) 管理设计数据：CAD 框架的五个维度、配置管理和产品数据管理，IEEE 会议录，卷。 84、第1期，1996年1月
As I said before in an answer to a similar question: The terminology used is not very precise. There is an article describing the five relevant dimensions. Data management tools for software development don't tend to support more than three of them consistently at the same time. If you want to support all five you have to describe a development proces:
Peter van den Hamer and Kees Lepoeter (1996) Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management, Proceedings of the IEEE, Vol. 84, No. 1, January 1996