开源规范
开源协议概述
业界有上百种开源协议，每种开源协议的要求不一样，有的协议对使用条件要求比较苛刻，有的则相对比价宽松
6种常见开源协议: GPL、MPL、LGPL、Apache、BSD和MIT
开源规范具有哪些特点
第一，开源项目，应该有一个高的单元覆盖率。这样，一方面可以确保第三方开发者在开发完代码之后，能够很方便地对整个项目做详细的单元测试，另一方面也能保证提交代码的质量
第二，要确保整个代码库和提交记录中，不能出现内部 IP、内部域名、密码、密钥这类信息。否则，就会造成敏感信息外漏，可能会对我们的内部业务造成安全隐患
第三，当我们的开源项目被别的开发者提交 pull request、issue、评论时，要及时处理，一方面可以确保项目不断被更新，另一方面也可以激发其他开发者贡献代码的积极性
第四，好的开源项目，应该能够持续地更新功能，修复 Bug。对于一些已经结项、不维护的开源项目，需要及时地对项目进行归档，并在项目描述中加以说明
文档规范
README 规范
# 项目名称
<!-- 写一段简短的话描述项目 -->
## 功能特性
<!-- 描述该项目的核心功能点 -->
## 软件架构(可选)
<!-- 可以描述下项目的架构 -->
## 快速开始
### 依赖检查
<!-- 描述该项目的依赖，比如依赖的包、工具或者其他任何依赖项 -->
### 构建
<!-- 描述如何构建该项目 -->
### 运行
<!-- 描述如何运行该项目 -->
## 使用指南
<!-- 描述如何使用该项目 -->
## 如何贡献
<!-- 告诉其他开发者如果给该项目贡献源码 -->
## 社区(可选)
<!-- 如果有需要可以介绍一些社区相关的内容 -->
## 关于作者
<!-- 这里写上项目作者 -->
## 谁在用(可选)
<!-- 可以列出使用本项目的其他有影响力的项目，算是给项目打个广告吧 -->
## 许可证
<!-- 这里链接上该项目的开源许可证 -->
项目文档规范
好的文档规范有 2 个优点：易读和可以快速定位文档
不同项目有不同的文档需求，在制定文档规范时，你可以考虑包含两类文档
-
开发文档：用来说明项目的开发流程，比如如何搭建开发环境、构建二进制文件、测试、部署等
-
用户文档：软件的使用文档，对象一般是软件的使用者，内容可根据需要添加。比如，可以包括 API 文档、SDK 文档、安装文档、功能介绍文档、最佳实践、操作指南、常见问题等
目录文档结构
docs
├── devel # 开发文档，可以提前规划好，英文版文档和中文版文档
│ ├── en-US/ # 英文版文档，可以根据需要组织文件结构
│ └── zh-CN # 中文版文档，可以根据需要组织文件结构
│ └── development.md # 开发手册，可以说明如何编译、构建、运行项目
├── guide
....
API 接口文档规范
接口文档又称为 API 文档，一般由后台开发人员编写，用来描述组件提供的 API 接口，以及如何调用这些 API 接口
在项目初期，接口文档可以解耦前后端，让前后端并行开发：前端只需要按照接口文档实现调用逻辑，后端只需要按照接口文档提供功能
接口文档有四种编写方式，包括编写 Word 格式文档、借助工具编写、通过注释生成和编写 Markdown 格式文档。具体的实现方式见下表：
| 实现方式 | 描述 |
| --- | --- |
| 编写Word格式文档 | 编写Word格式的接口文档。Word格式强大的排版能力，可以满足不同的API编写需求 |
| 借助工具编写 | 借助在线或离线的API文档编写工具编写接口文档，这些工具通常已经定义好了接口文档的格式，只需按照格式填写内容即可。通过编写工具写文档，简单省事，格式统一 |
| 通过注释生成 | 在代码中添加注释，并通过Swagger工具生成符合Swagger规范的接口文档，这种方式更新比较方便 |
| 编写Markdown格式文档 |在项目仓库中，编写Markdown格式的接口文档。因为Markdown轻量，占用空间小的特性 |
一个完整的 API 接口介绍文档、API 接口变更历史文档、通用说明、数据结构说明、错误码描述和 API 接口使用文档。API 接口使用文档中需要包含接口描述、请求方法、请求参数、输出参数和请求示例
-
README.md ：API 接口介绍文档，会分类介绍 IAM 支持的 API 接口，并会存放相关 API 接口文档的链接，方便开发者查看
-
CHANGELOG.md ：API 接口文档变更历史，方便进行历史回溯，也可以使调用者决定是否进行功能更新和版本更新
-
generic.md ：用来说明通用的请求参数、返回参数、认证方法和请求方法等
-
struct.md ：用来列出接口文档中使用的数据结构。这些数据结构可能被多个 API 接口使用，会在 user.md、secret.md、policy.md 文件中被引用
-
user.md 、 secret.md 、 policy.md ：API 接口文档，相同 REST 资源的接口会存放在一个文件中，以 REST 资源名命名文档名
-
error_code.md ：错误码描述，通过程序自动生成
版本规范
在做 Go 项目开发时，我建议你把所有组件都加入版本机制
原因主要有两个：
-
一是通过版本号，我们可以很明确地知道组件是哪个版本，从而定位到该组件的功能和代码，方便我们定位问题
-
二是发布组件时携带版本号，可以让使用者知道目前的项目进度，以及使用版本和上一个版本的功能差别等
什么是语义化版本规范（SemVer）？
语义化版本规范（SemVer，Semantic Versioning）是 GitHub 起草的一个具有指导意义的、统一的版本号表示规范。它规定了版本号的表示、增加和比较方式，以及不同版本号代表的含义
在这套规范下，版本号及其更新方式包含了相邻版本间的底层代码和修改内容的信息。语义化版本格式为：主版本号.次版本号.修订号（X.Y.Z），其中 X、Y 和 Z 为非负的整数，且禁止在数字前方补零
版本号可按以下规则递增
-
主版本号（MAJOR）：当做了不兼容的 API 修改
-
次版本号（MINOR）：当做了向下兼容的功能性新增及修改。这里有个不成文的约定需要你注意，偶数为稳定版本，奇数为开发版本
-
修订号（PATCH）：当做了向下兼容的问题修正
例如，v1.2.3 是一个语义化版本号，版本号中每个数字的具体含义见下图:
还有另一种版本： v1.2.3-alpha
语义化版本控制规范
标记版本号的软件发行后，禁止改变该版本软件的内容，任何修改都必须以新版本发行
主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变，这样的公共 API 不应该被视为稳定版。1.0.0 的版本号被界定为第一个稳定版本，之后的所有版本号更新都基于该版本进行修改
修订号 Z（x.y.Z | x > 0）必须在只做了向下兼容的修正时才递增，这里的修正其实就是 Bug 修复
次版本号 Y（x.Y.z | x > 0）必须在有向下兼容的新功能出现时递增，在任何公共 API 的功能被标记为弃用时也必须递增，当有改进时也可以递增。其中可以包括修订级别的改变。每当次版本号递增时，修订号必须归零
主版本号 X（X.y.z | X > 0）必须在有任何不兼容的修改被加入公共 API 时递增。其中可以包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须归零
如何确定版本号？
第一，在实际开发的时候，建议你使用 0.1.0 作为第一个开发版本号，并在后续的每次发行时递增次版本号
第二，当我们的版本是一个稳定的版本，并且第一次对外发布时，版本号可以定为 1.0.0
第三，当我们严格按照 Angular commit message 规范提交代码时，版本号可以这么来确定
-
fix 类型的 commit 可以将修订号+1
-
feat 类型的 commit 可以将次版本号+1
-
带有 BREAKING CHANGE 的 commit 可以将主版本号+1
