软件开发之版本管理Versioning
软件开发之版本管理Versioning
- SemVer规范
- 语义化版本控制规范(SemVer)
- 实践示例参考
- Electron
- NVIDIA
软件开发中，版本管理看似微不足道，但如果着手开发前有一份清晰完整的版本管理规范，相信会对软件后续的开发和维护大有裨益，这里摘抄一些比较流行和成熟的指导规范以供参考。
SemVer规范
Link
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
语义化版本控制规范(SemVer)
以下关键词 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL 依照 RFC 2119 的叙述解读。
- 使用语义化版本控制的软件必须（MUST）定义公共 API。该 API 可以在代码中被定义或出现于严谨的文件内。无论何种形式都应该力求精确且完整。
- 标准的版本号必须（MUST）采用 X.Y.Z 的格式，其中 X、Y 和 Z 为非负的整数，且禁止（MUST NOT）在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须（MUST）以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
- 标记版本号的软件发行后，禁止（MUST NOT）改变该版本软件的内容。任何修改都必须（MUST）以新版本发行。
- 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。
- 1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。
- 修订号 Z（x.y.Z | x > 0）必须（MUST）在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。
- 次版本号 Y（x.Y.z | x > 0）必须（MUST）在有向下兼容的新功能出现时递增。在任何公共 API 的功能被标记为弃用时也必须（MUST）递增。也可以（MAY）在内部程序有大量新功能或改进被加入时递增，其中可以（MAY）包括修订级别的改变。每当次版本号递增时，修订号必须（MUST）归零。
- 主版本号 X（X.y.z | X > 0）必须（MUST）在有任何不兼容的修改被加入公共 API 时递增。其中可以（MAY）包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须（MUST）归零。
- 先行版本号可以（MAY）被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白。数字型的标识符禁止（MUST NOT）在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
- 版本编译信息可以（MAY）被标注在修订版或先行版本号之后，先加上一个加号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白。当判断版本的优先层级时，版本编译信息可（SHOULD）被忽略。因此当两个版本只有在版本编译信息有差别时，属于相同的优先层级。范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。
- 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须（MUST）把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较（版本编译信息不在这份比较的列表中）。由左到右依序比较每个标识符，第一个差异值用来决定优先层级：主版本号、次版本号及修订号以数值比较，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时，改以优先层级比较低的先行版本号决定。例如：1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号，其优先层级必须（MUST）透过由左到右的每个被句点分隔的标识符来比较，直到找到一个差异值后决定：只有数字的标识符以数值高低比较，有字母或连接号时则逐字以 ASCII 的排序来比较。数字的标识符比非数字的标识符优先层级低。若开头的标识符都相同时，栏位比较多的先行版本号优先层级比较高。范例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。
实践示例参考
Electron
Versioning
| Major Version Increments | Minor Version Increments | Patch Version Increments |
|---|---|---|
| Electron breaking API changes | Electron non-breaking API changes | Electron bug fixes |
| Node.js major version updates | Node.js minor version updates | Node.js patch version updates |
| Chromium version updates | fix-related chromium patches |
NVIDIA
Driver Lifecycle
- DRV
Regular Driver Release Branch every 3 months - New Feature Branch (NFB)
Major feature release, indicated by a new branch X number. This is targeted towards early adopters who want to evaluate new features (e.g. new CUDA APIs). Note that these drivers may also be shipped along with CUDA Toolkit installer packages in some cases. - Production Branch(PB)
Branch that is qualified for use in production for enterprise/datacenter GPUs. Bug fixes and security updates are provided for up to 1 year. - Long Term Support Branch(LTSB)
A production branch that will be supported and maintained for a much longer time than a normal production branch is supported. Every LTSB is a production branch, but not every production branch is an LTSB.
| N/A | New Feature Branch (NFB) | Production Branch (PB) | Long Term Support Branch (LTSB) |
|---|---|---|---|
| Target Customers | Early adopters who want to evaluate new features | Use in production for enterprise/datacenter GPUs | Use in production for enterprise/datacenter GPUs and for customers looking for a longer cycle of support. |
| Major Release Cadence | At least once every 3 months | Twice a year. See also note below | At least once per hardware architecture. See also note below |
| Length of support | N/A | 1 year | 3 years |
| Minor release (bug updates and critical security updates) | N/A | Yes. Quarterly bug and security releases for 1 year. | Yes. Quarterly bug and security releases for 1 year. |
软件开发之版本管理Versioning相关推荐
- 【软件开发】制作个人移动式Git服务器
使用场景 软件开发需要进行版本管理,当下流行的版本管理工具有Git.SVN等.在线的Git服务提供商也有很多,如Github.码云.码市等.使用在线的Git服务的有一些缺点,如 可能有容量限制 可能有 ...
- 软件开发工具（第1章：绪论）
一. 软件开发工具的由来 计算机语言和软件开发工具的发展和历史 机器语言(第一代语言):难以记忆的.无意义的.二进 制的字符串 汇编语言(第二代语言)针对难以记忆的.无意义的.二进 制的字符串.人们试 ...
- 华为软件开发云发布管理测评报告
华为软件开发云的发布管理是面向软件开发者提供软件组件仓库,生命周期,内部及第三方依赖等管理服务,支撑产品持续发布,提升发布质量及效率.目前发布管理支持提供了Maven私有仓.中央仓代理.内部组件依赖管 ...
- 软件开发中团队能力的培养
团队开发已经成为现在软件开发的主要形式,随着软件产业的发展,团队开发也越来越重要.所以,对新手的团队开发能力的培养,就成为一个必要问题.在这篇博客里,只谈论一下我浅薄的人识. 加强新手对团队开发的认识 ...
- 软件开发中常见知识总结
最近在准备软件开发的笔试面试,复(yu)习(xi)了一些在软件开发中的常见知识.为了给自己攒点RP,故与大家分享一二. 软件开发需要准备的比较多,主要分为编程语言,数据结构和算法,计算机网络,计算机操 ...
- 地平线：面向规模化量产的智能驾驶系统和软件开发
导读 7月27日,地平线在智东西公开课开设的「地平线自动驾驶技术专场」第3讲顺利完结,地平线智能驾驶应用软件部负责人宋巍围绕 <面向规模化量产的智能驾驶系统和软件开发>这一主题进行了直播讲 ...
- 100本软件开发最佳书籍排行榜
由NOOP网站评出的一份排行榜,名称为"Top 100 Best Software Engineering Books, Ever ".列出100本顶尖的软件开发书籍,主要根据以下 ...
- 转载 100本软件开发最佳书籍排行榜
由NOOP网站评出的一份排行榜,名称为"Top 100 Best Software Engineering Books, Ever ".列出100本顶尖的软件开发书籍,主要根据以下 ...
- 软件开发工具与环境 （课程代码：07169）
软件开发工具与环境 (课程代码:07169) 试题 一次测评 二次测评 试题 一次测评 1.第三代程序设计语言属于 A.汇编语言 B.机器语言 C.过程化语言 D.非过程化语言 2.软件开发环境的主要 ...
最新文章
- 初级Java程序员所面临的4大挑战
- 《netty入门与实战》笔记-02：服务端启动流程
- 如何计算神秘的Google Adwords 品质分数– 提升到10分神的境界
- python 下载文件-Python实现批量下载文件
- linux关闭rac某一节点,实现多次不完全恢复（RAC环境需要将另一节点关闭）
- 现在哪款诺基亚能玩Java游戏_回忆S60（塞班）年代的JAVA游戏：有没有哪一款是你在课堂偷偷玩的？...
- Proxyee Down百度网盘高速下载器详细使用教程
- java学习感想_Java学习感想
- 期货高手:文华财经博易大师指标公式提取源码还原源码编写教程分享
- Cannot truncate table 'xxx' because there are one or more isolation level 0 scans, or REO
- 项目团队研发人员离职，如何做好交接？| 每天成就更大成功
- tensorflow2计算flops
- Coder HDU - 4288
- 虾皮面试真题：虾皮后端15连问！
- Lab: Password reset poisoning via middleware：通过中间件使密码重置中毒靶场复盘
- 网络安全笔记-TCP/IP
- WEB-easy_upload
- html电话号码表单验证,表单验证电话号码模式html5(Form Validation phone number pattern html5)...
- Java中POJO及其细分XO、DAO的概念
- 集成电机驱动方案（STM32+DRV8841）