- 1Ollama管理本地开源大模型，用Open WebUI访问Ollama接口_ollama下载后怎么访问
- 2AI时代？——Python与open AI之间的联系_openai编程语言
- 3微服务架构下，SpringCloud集成分布式文件存储中间件：FastDFS
- 4医院信息系统集成平台—数据中心_医院集成系统
- 5C#中的垃圾回收、资源清理及推迟初始化_c# 清理解决方案
- 6本科程序员转行做保姆，月薪每月1万3，声称比做白领挣得多_码农的尽头是保姆
- 7李宏毅生成式AI课程——Diffusion Model（1）
- 8基础课20——智能客服系统的使用维护
- 9c++正则表达式的组成和使用
- 10python获取对象信息和实例属性和类属性_python获取实例所有属性
带你了解软件版本号的命名规则_版本号命名规则
赞
踩
1、 常见软件的版本号命名
| 软件 | 升级过程 | 说明 |
|---|---|---|
| Linux Kernel | 0.0.1 / 1.0.0 / 2.6.32 / 3.0.18 /… | 若用 X.Y.Z 表示，则偶数 Y 表示稳定版本，奇数 Y 表示开发版本。 |
| Windows | Windows 98 / Windows 2000 / Windows XP /Windows 7 / … | 最大的特点是杂乱无章，毫无规律。 |
| SSH Client | 0.9.8 | |
| OpenStack | 2014.1.3 / 2015.1.1.dev8 |
从上可以看出，不同的软件版本号风格各异，随着系统的规模越大，依赖的软件越多，如果这些软件没有遵循一套规范的命名风格，容易造成 Dependency Hell。所以当我们发布版本时，版本号的命名需要遵循某种规则，其中 Semantic Versioning 2.0.0 定义了一套简单的规则及条件来约束版本号的配置和增长。本文根据 Semantic Versionning 2.0.0 和 Semantic Versioning 3.0.0 选择性的整理出版本号命名规则指南。
2、 语义化版本命名通行规则
该规则对版本的迭代顺序命名做了很好的规范，其版本号的格式为 X.Y.Z(又称 Major.Minor.Patch)，递增的规则为：
| 序号 | 格式要求 | 说明 |
|---|---|---|
| X | 非负整数 | 表示主版本号(Major)，当 API 的兼容性变化时，X 需递增。 |
| Y | 非负整数 | 表示次版本号(Minor)，当增加功能时(不影响 API 的兼容性)，Y 需递增。 |
| Z | 非负整数 | 表示修订号（Patch），当做 Bug 修复时(不影响 API 的兼容性)，Z 需递增 |
详细的使用规则如下：
X, Y, Z 必须为非负整数，且不得包含前导零，必须按数值递增，如 1.9.0 -> 1.10.0 -> 1.11.0。
0.Y.Z 的版本号表明软件处于初始开发阶段，意味着 API 可能不稳定；1.0.0 表明版本已有稳定的API。
当 API 的兼容性变化时，X 必须递增，Y 和 Z 同时设置为 0；当新增功能(不影响 API 的兼容性)或者 API 被标记为 Deprecated 时，Y 必须递增，同时 Z 设置为 0；当进行 bug fix 时，Z 必须递增。
先行版本号(Pre-release)意味该版本不稳定，可能存在兼容性问题，其格式为：X.Y.Z.[a-c][正整数]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。
开发版本号常用于 CI-CD，格式为 X.Y.Z.dev[正整数]，如 1.0.1.dev4。
版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如 1.0.0 < 1.0.1 < 1.1.1 <2.0.0；对于先行版本号和开发版本号，有：1.0.0.a100 < 1.0.0，2.1.0.dev3 < 2.1.0；当存在字母时，以 ASCII 的排序来比较，如 1.0.0.a1 < 1.0.0.b1。
注意：版本一经发布，不得修改其内容，任何修改必须在新版本发布！
3、商业软件中常见的修饰词
| 描述方式 | 说明 | 含义 |
|---|---|---|
| Snapshot | 快照版 | 尚不不稳定、尚处于开发中的版本 |
| Alpha | 内部版 | 严重缺陷基本完成修正并通过复测，但需要完整的功能测试 |
| Beta | 测试版 | 相对 Alpha 有很大的改进，消除了严重的错误，但还是存在一些缺陷 |
| RC | 终测版 | Release Candidate（最终测试），即将作为正式版发布。 |
| Demo | 演示版 | 只集成了正式版部分功能升级，无法升级 |
| SP | SP1 | 是 service pack 的意思表示升级包，相信大家在 windows 中都见过。 |
| Release | 稳定版 | 功能相对稳定，可以对外发行，但有时间限制 |
| Trial | 试用版 | 试用版，仅对部分用户发行 |
| Full Version | 完整版 | 即正式版，已发布。 |
| Unregistered | 未注册 | 有功能或时间限制的版本 |
| Standard | 标准版 | 能满足正常使用的功能的版本 |
| Lite | 精简版 | 只含有正式版的核心功能 |
| Enhance | 增强版 | 正式版，功能优化的版本 |
| Ultimate | 旗舰版 | 在标配版本升级体验感更好的版本 |
| Professiona | 专业版 | 针对更高要求功能，专业性更强的使用群体发行的版本 |
| Free | 自由版 | 自由免费使用的版本 |
| Upgrade | 升级版 | 有功能增强或修复已知 bug |
| Retail | 零售版 | 单独发售 |
| Cardware | 共享版 | 公用许可证（IOS 签证） |
| LTS | 维护版 | 该版本需要长期维护 |
4、 软件版本号使用限定
为了方便理解,版本限定的语法简述为为 [范围描述]<版本号描述>
范围描述可选,必须配和版本描述确定范围,无法独立存在
< 小于某一版本号
<= 小于等于某一版本号
> 大于某一版本号
>= 大于等于某一版本号
= 等于某一版本号,没有意义和直接写该版本号一样
~ 基于版本号描述的最新补丁版本
^ 基于版本号描述的最新兼容版本
- 某个范围,他应该出现在两个版本描述中间,实际上语法应为 <版本描述>-<版本描述>,写在此处为了统一
严格来讲对 ~,^ 的表述需要结合具体的包管理工具和版本号规则来确定.但是对于一般使用记住如下原则：
^ 是确保版本兼容性时,默认对次版本号的限定约束
~ 是确保版本兼容性时,默认对补丁号的约束
