软件的版本号变更有啥原则?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件的版本号变更有啥原则?相关的知识,希望对你有一定的参考价值。
参考技术A 为了维护软件项目, 我们提出了对版本进行管理控制的要求. 而对于用户来说, 版本直接体现在版本号的命名上. 那么, 如何对版本号进行命名呢? 我查了许多的资料, 希望能解释得比较具体, 同时也希望您在阅读本文的时候, 能够对版本号的命名格式提出自己的见解, 这当然包括一些版本号命名的个例. 下面, 让我们看一下比较普遍的 3 种命名格式.GNU 风格的版本号命名格式: 主版本号.子版本号[.修正版本号[.编译版本号]]
英文对照: Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]
示例: 1.2.1, 2.0, 5.0.0 build-13124
Windows 风格的版本号命名格式: 主版本号.子版本号[修正版本号[.编译版本号]]
英文对照: Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]
示例: 1.21, 2.0
.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]]
英文对照: Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]
官方说明参考:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemVersionClassTopic.asp
由于, 有官方解释, 所以本文不做说明.
GNU 风格的版本号管理策略
当项目初版本时, 版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0, 如果你为人很低调, 我想你会选择那个主版本号为 0 的方式;
当项目在进行了局部修改或 bug 修正时, 主版本号和子版本号都不变, 修正版本号加 1;
当项目在原有的基础上增加了部分功能时, 主版本号不变, 子版本号加 1, 修正版本号复位为 0, 因而可以被忽略掉;
当项目在进行了重大修改或局部修正累积较多, 而导致项目整体发生全局变化时, 主版本号加 1;
另外, 编译版本号一般是编译器在编译过程中自动生成的, 我们只定义其格式, 并不进行人为的控制.
Window 下的版本号管理策略
当项目初版时, 版本号为 1.0 或 1.00;
当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变, 修正版本号加 1;
当项目在原有的基础上增加了部分功能时, 主版本号不变, 子版本号加 1, 修正版本号复位为 0, 因而可以被忽略掉;
当项目在进行了重大修改或局部修正累积较多, 而导致项目整体发生全局变化时, 主版本号加 1;
另外, 编译版本号一般是编译器在编译过程中自动生成的, 我们只定义其格式, 并不进行人为的控制.
另外, 还可以在版本号后面加入 Alpha, Beta, Gamma, Current, RC (Release Candidate), Release, Stable 等后缀, 在这些后缀后面还可以加入 1 位数字的版本号.
对于用户来说, 如果某个软件的主版本号进行了升级, 用户还想继续那个软件, 则发行软件的公司一般要对用户收取升级费用; 而如果子版本号或修正版本号发生了升级, 一般来说是免费的.
参考资料:http://www.woodpecker.org.cn:9081/doc/zScrapBook/data/20051010111809/
本回答被提问者采纳软件版本号规范与命名原则(node.js与package.json依赖包规范)
文章目录
1、软件版本号
一般来讲大部分的软件版本号分3段,比如 A.B.C
- A 表示大版本号,一般当软件整体重写,或出现不向后兼容的改变时,增加A,A为零时表示软件还在开发阶段。
- B 表示功能更新,出现新功能时增加B
- C 表示小修改,如修复bug,只要有修改就增加C
2、版本号的修饰词
- 日期版本号:表示发布日期
- alpha: 内部测试版,bug较多,主要是修改和实现功能
- beta: 测试版,大部分bug已修,主要是修改UI和小bug等
- rc: 即将作为正式版发布
- lts: 长期维护
- release版: 该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式版本,是最终交付用户使用的一个版本。该版本有时也称为标准版。
3、大厂常用的版本号
微软
RC(Release Candidate):候选版本,这一版本不会增加新功能,多要进行Debug
GA(General Available):正式发布版本,这个版本就是正式的版本
RTM(Release to Manufacture):给工厂大量生产的压片版本,与正式版内容一样
OEM(Original Entrusted Manufacture):给计算机厂商的出场销售版本,不零售只预装
RVL:号称是正式版,其实RVL根本不是版本的名称。它是中文版/英文版文档破解出来的
EVAL:而流通在网络上的EVAL版,与“评估版”类似,功能上和零售版没有区别
RTL(Retail):零售版是真正的正式版,正式上架零售版
谷歌与chrome
GM(Gold Master):正式版前最后一个测试版,其实也就是正式版
Chromium:开源版本,迭代速度极快,数小时就会有新版本,有很多新功能,等待验证后会移植到Chrome
Canary:迭代速度相对于Chromium版稍慢一些,功能非常新但未经过验证,同时崩溃的概率非常高
Dev:基于Chromium开发,每周出新功能,并且这些功能还有一定的筛选,另外还修复了一些Bug和不稳定因素
Beta:基于Dev版,Chrome会基于这一版本进行改进,一般按月更新,功能更加完善
Stable:稳定版本,也就是Chrome的正式版本,这一版本基于Beta版,已知Bug都被修复,一般情况下,更新比较慢
4、版本号的阶段标识
软件的每个版本中包括11个阶段,详细阶段描述如下:
阶段名称 | 阶段标识 |
---|---|
需求控制 | a |
设计阶段 | b |
编码阶段 | c |
单元测试 | d |
单元测试修改 | e |
集成测试 | f |
集成测试修改 | g |
系统测试 | h |
系统测试修改 | i |
验收测试 | j |
验收测试修改 | k |
5、(node.js中的)^和~区别
当我们查看项目配置文件package.json中已安装的库的时候,会发现他们的版本号之前都会加一个符号,有的是插入符号(^),有的是波浪符号(~)
- 当使用npm install 安装包时,默认会在包的版本号前面添加^符号
- 当在包的版本号前面插入波浪符号~时,表示当更新包时,锁定次版本,将补丁版本更至最新;例如 ~1.15.2 ,表示 >=1.15.2 && <1.16.0;
- 当在包的版本号前面插入符号^时,表示当更新包时,锁定主版本,将次版本更到最新;例如 \\ ^3.3.4 ,表示 >=3.3.4 && <4.0.0
以上是关于软件的版本号变更有啥原则?的主要内容,如果未能解决你的问题,请参考以下文章
软件版本号规范与命名原则(node.js与package.json依赖包规范)