文档 Semantic Versioning 细粒度问题

[ArtShiba]

我注意到近期几个版本的文档更新在文档版本切换时将细粒度进行了提升，由

<major> "." <minor> " # 1.13

变为了：

<major> "." <minor> "." <patch>" # 1.13.1

该做法在文档页面中并不常见，好奇这是出于何种考究？通常如果采取此做法，则建议在小的 patch 版本停止更新后，将默认的 minor 版本展示为对应的最新版，参考 pandas 实现。例如：如果 1.12.4 是 1.12 的最后一个版本，那么在 JSON 格式的配置文件中，应当只保留 1.12 并指向 1.12.4 的镜像，而非让 1.12 与 1.12.4 在版本切换器中共存；1.13.0 与 1.13.1 同理。

P.S: 目前的用于 Action 的 OSS 脚本 只能比较笨拙地添加新的 version 信息到 JSON 配置中，无法删除，因此可能需要手动更新位于 OSS 上的相应文件（基本操作教程，用到的密钥等信息请询问相关负责人员），或完善脚本逻辑支持删除指定版本。

猜测需要共存两个不同的 patch 版本的可能有：

1. 引入了新的 API 改动（如 v1.13.1 添加 emboss, sharpen, linearcontrast 算子），担心如果用户在使用 1.13.0 版本 MegEngine 并查询文档时发现新增接口信息的不一致。参考解决办法：在相应的 API 接口的 docstring 中添加有关 directives:

   .. versionadded:: 1.13.1
   

   则用户在查看相应 API 页面时能清晰地获取新增与变动的版本信息。

2. 为了方便在 patch 版本的 Wheel 包在没有 Release 之前，能更方便地提前更新 main 分支文档而不产生类似于找不到 API 的 warnings 信息。解决方法：理解这个目的，但我们不能死脑筋，完全可以再开一个新的 v1.13.1 的 branch 并且在里面更新文档（它不是 main 或 dev 分支，因此不会触发 CI），所有的预览在本地 Build 进行，待到外部（PyPI 或镜像源）能获取发布后的 Wheel 包之后，Rebase 到 main 分支。

3. 由于新版本的变化，GitHub Action 提供的免费 Worker 已经不满足 Dev 分支的原生最简编译要求（空间不够），因此全面转向了基于预编译发布的 Wheel 包的文档构建方式。解决方法：使用贵司内部的 Workspace 机器代替 GitHub 免费提供的 Worker, 请找 CI 相关负责人获取支持，参考 MegEngine 的 CPU 编译.

4. 如果有什么其它的缘由，可以讨论一下。

[ArtShiba]

第 #520 个 Issue, 我对这片土地爱得深沉。