版本号命名规则

参考：

​ https://blog.csdn.net/u012107143/article/details/78731272

​ http://wsfdl.com/devops/2016/09/27/%E7%89%88%E6%9C%AC%E5%8F%B7.html

​ https://semver.org/lang/zh-CN/

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. 项目立项时

版本格式：0.0.0

3. 开发阶段时

此时系统尚不稳定，随时可能增减或者修正API。

版本格式：0.次版本号.修订号，版本号递增规则如下：

主版本号：0表示正在开发阶段； 次版本号：增加新的功能时增加； 修订号：只要有改动就增加。

4. 开发完成后，发布API，或进入二方库时

此时系统已经基本稳定，可以对外公布使用，意味着API不再会被随意修改。

版本格式：1.0.0

5. 后续的维护升级时

没有特殊需求不会修改API，尤其是对API进行不兼容的升级，或弃用时要特别谨慎。如果需要弃用API，要提前在一个或几个版本中加入弃用标示或注解，并在文档中，建议用户更换为其他可替换的API，然后在下个主版本号升级时，再真正丢掉弃用的API。

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：全盘重构时增加；重大功能或方向改变时增加；大范围不兼容之前的接口时增加； 次版本号：增加新的业务功能时增加； 修订号：增加新的接口时增加；在接口不变的情况下，增加接口的非必填属性时增加；增强和扩展接口功能时增加。 新增接口：如果该新增的接口只是对现有的业务线进行扩展则增加修订号；如果是为了增加新的业务线则增加次版本号。

6. 先行版本号和开发版本号

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

先行版本号(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。

7. 一些修饰的词

• alpha：内部版本
• beta：测试版
• demo：演示版
• enhance：增强版
• free：自由版
• full version：完整版，即正式版
• lts：长期维护版本
• release：发行版
• rc：即将作为正式版发布
• standard：标准版
• ultimate：旗舰版
• upgrade：升级版

8. 特别注意：

1. 版本一经发布，不得修改其内容，任何修改必须在新版本发布！
2. 在接口还没有确定下来的时候，应该先使用开发版本号。
3. 业务功能 > 功能 > 接口

0. 前言

版本号的命名和更新问题，是开发者的责任感和前瞻性的问题。

1. 项目立项时

版本格式：0.0.0

2. 开发阶段时

此时系统尚不稳定，随时可能增减或者修正API。

版本格式：0.次版本号.修订号，版本号递增规则如下：

1. 主版本号：0表示正在开发阶段；
2. 次版本号：增加新的功能时增加；
3. 修订号：只要有改动就增加。

3. 开发完成后，发布API，或进入二方库时

此时系统已经基本稳定，可以对外公布使用，意味着API不再会被随意修改。

版本格式：1.0.0

4. 后续的维护升级时

没有特殊需求不会修改API，尤其是对API进行不兼容的升级，或弃用时要特别谨慎。如果需要弃用API，要提前在一个或几个版本中加入弃用标示或注解，并在文档中，建议用户更换为其他可替换的API，然后在下个主版本号升级时，再真正丢掉弃用的API。

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

1. 主版本号：全盘重构时增加；重大功能或方向改变时增加；大范围不兼容之前的接口时增加；
2. 次版本号：增加新的业务功能时增加；
3. 修订号：增加新的接口时增加；在接口不变的情况下，增加接口的非必填属性时增加；增强和扩展接口功能时增加。

新增接口：如果该新增的接口只是对现有的业务线进行扩展则增加修订号；如果是为了增加新的业务线则增加次版本号。

5. 先行版本号和开发版本号

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

1. 先行版本号(Pre-release)：意味该版本不稳定，可能存在兼容性问题。 其格式为：X.Y.Z.[a-c][正整数]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。
2. 开发版本号：常用于 CI-CD（持续集成和持续交付）。 格式为 X.Y.Z-dev[正整数]，如 1.0.1-dev4。
3. 版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如 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。

特别注意：

1. 版本一经发布，不得修改其内容，任何修改必须在新版本发布！
2. 在接口还没有确定下来的时候，应该先使用开发版本号。
3. 业务功能 > 功能 > 接口

推荐阅读：
版本号命名指南
版本号命名规则-语义化版本 2.0.0 | Semantic Versioning

————————————————
版权声明：本文为CSDN博主「frcoder」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012107143/article/details/78731272

gradle caches第三方库子目录缓存文件夹命名规则

其实缓存目录中存放每个库文件的文件夹名字就是相应文件的sha1值

在android项目中，gradle会缓存一些第三方库。有时会出现第三方库在android studio内无法下载，导致项目无法通过编译，但是Gradle log显示的下载地址，在浏览器打开是可以下载下来的，对于这种问题解决起来思路很简单，用浏览器下载下来，放到对应得目录下，项目即可编译。

第一步：找到缓存目录

本文使用Everything 软件来快速搜索 （下载地址 ：http://www.voidtools.com/）

下边以项目中的rxjava:3.0.0举例

    implementation 'io.reactivex.rxjava3:rxjava:3.0.0'

在Everything 搜索rxjava3

点进去会发现在在以版本号（3.0.0）命名的目录下还有一些奇怪的文件目录

每个目录其实对应不同的库文件

第2步：目录命名规则

https://mvnrepository.com/artifact/io.reactivex.rxjava3/rxjava/3.0.0

点击View All进去，发现4个库文件都有

其实缓存目录中存放每个库文件的文件夹名字就是相应文件的sha1 值

现在就以rxjava-3.0.0-javadoc.jar来验证一下

总结

当出现第三方库在android studio内无法下载时，可以在 https://mvnrepository.com/
下载相应的库文件，放到以每个库文件的文件的sha1值来命名存放目录下，即可解决该问题。