A：版本状态段规则

B：Go 项目开发阶段介绍

业界标准的 Go 项目研发流程如下图所示：

每个阶段结束时，都需要有一个最终的产出物，可以是文档、代码或者部署组件等。这个产出物既是当前阶段的结束里程碑，又是下一阶段的输入。每个阶段又细分为很多步骤，这些步骤是需要不同的参与者去完成的工作任务。具体每个阶段研发需要参与的工作介绍如下：

• 需求阶段： 需求阶段是产品人员的主战场，产品人员会讨论产品思路、调研市场需求，并对需求进行分析，最终整理出一个需要研发人员去实现的需求文档。

• 设计阶段： 设计阶段包含了很多内容，例如：产品设计、交互设计、视觉设计、技术设计等。开发人员，根据产品需求，调研最优的技术方案，经过多轮技术评审最终形成一个技术方案文档，之后会根据改技术方案文档，进行项目开发。

• 开发阶段： 开发阶段是研发人员的主战场，这个阶段研发人员会结合需求文档、技术文档，编写代码实现产品需求。开发阶段的产出物是满足需求的源代码、开发文档，以及编译后的归档文件。

• 测试阶段： 测试阶段是测试工程师的主战场，测试工程师根据需求文档创建测试计划、编写测试用例，并拉研发同学一起评审测试计划和用例。评审通过后，测试工程师就会根据测试计划和测试用例对服务进行测试。测试阶段的产出物是满足产品需求、达到发布条件的源代码，以及编译后的归档文件。

• 发布阶段： 该阶段，研发/运维会将测试后的制品发布到现网，为了保证发布效率和质量，这个阶段通常会借助一些 CI/CD 平台来自动化的完成代码的构建和发布。

• 运营阶段： 研发流程的最后一个阶段是运营阶段，该阶段主要分为产品运营和运维两个部分。

• 产品运营： 通过一系列的运营活动，比如线下的技术沙龙、线上的免费公开课、提高关键词排名或者输出一些技术推广文章等方式，来推高整个产品的知名度，提高产品的用户数量，并提高月活和日活。

• 运维： 由运维工程师负责，核心目标是确保系统稳定的运行，如果系统异常，能够及时发现并修复问题。长期目标是通过技术手段或者流程来完善整个系统架构，减少人力投入、提高运维效率，并提高系统的健壮性和恢复能力。

C：开源规范协议介绍

当前有上百种开源协议可供选择，常用的有以下 6 种：

• GPL： General Public License，开源项目最常用的许可证，衍生代码的分发需开源并且也要遵守此协议。该协议也有很多变种，不同变种要求会略微不同。

• MPL： MPL 协议允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者，这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。

• LGPL： Lesser General Public Licence，是 GPL 的一个为主要为类库使用设计的开源协议。LGPL 允许商业软件通过类库引用的方式使用 LGPL 类库而不需要开源商业软件的代码。但是如果修改 LGPL 协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。

• Apache： Apache 协议是 Apache 软件基金会发布的一个自由软件许可证，Apache 2.0 协议除了为用户提供版权许可之外，还有专利许可，非常适合涉及专利内容的项目。

• BSD： BSD（Berkeley Software Distribution，伯克利软件发行版）。BSD 协议在软件分发方面，除需要包含一份版权提示和免责声明之外，没有任何限制，该协议还禁止用开源代码的作者/机构名字和原来产品的名字做市场推广。

• MIT： 协议的主要内容为：该软件及其相关文档对所有人免费，可以任意处置，包括使用，复制，修改，合并，发表，分发，再授权，或者销售。唯一的限制是，软件中必须包含上述版权和许可提示。MIT 协议是所有开源许可中最宽松的一个，除了必须包含许可声明外，再无任何限制。

你可以根据需要选择适合你项目的开源协议，如果觉得不好选择，可以参考下图进行选择：

上图中，右边的协议比左边的协议宽松，在选择时，你可以根据菱形框中的选择项从上到下进行选择。

另外，因为 Apache 是对商业应用友好的协议，使用者也可以在需要的时候修改代码来满足需要，并作为开源或商业产品发布/销售，所以大型公司的开源项目通常会采用 Apache 2.0 开源协议。

D：SemVer 版本规范内容

语义化版本控制规范比较多，我挑选一些比较重要的规范罗列如下：

• 使用语义化版本控制的软件必须定义公共 API。该 API 可以在代码中被定义或出现于严谨的文件内。无论何种形式都应该力求精确且完整。

• 版本号必须采用 X.Y.Z 的格式，其中 X、Y 和 Z 为非负的整数，且禁止在数字前方补零。X 是主版本号、Y 是次版本号、Z 为修订号。每个元素必须以数值来递增。例如：1.1.1 -> 1.2.0 -> 1.3.0。

• 标记版本号的软件发行后，禁止改变该版本软件的内容，任何修改都必须以新版本发行。

• 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变，这样的公共 API 不应该被视为稳定版。

• 1.0.0 的版本号被界定为第一个稳定版本，之后的所有版本号更新都基于该版本进行修改。

• 1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。

• 修订号 Z（x.y.Z | x > 0）必须在只做了向下兼容的修正时才递增，这里的修正其实就是Bug 修复。

• 次版本号 Y（x.Y.z | x > 0）必须在有向下兼容的新功能出现时递增，在任何公共 API 的功能被标记为弃用时也必须递增，当有改进时也可以递增。其中可以包括修订级别的改变。每当次版本号递增时，修订号必须归零。

• 主版本号 X`（`X.y.z | X > 0）必须在有任何不兼容的修改被加入公共 API 时递增。其中可以包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须归零。

• 先行版本号可以被标注在修订版之后，被标上先行版本号则表示这个版本并不稳定且可能无法满足预期的兼容性要求。例如：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。带先行版本号的格式为：X.Y.Z-先行版本号，先行版本号必须由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，数字型的标识符禁止在前方补零。

• 版本编译元数据可以被标注在修订版或先行版本号之后，先加上一个加号（+），再加上一连串以句点分隔的标识符来修饰。标识符必须由ASCII字母数字和连接号 [0-9A-Za-z-] 组成，且禁止留白。例如：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。

• 不同版本在判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后逐次进行比较。

提示：关于语义化版本号，更详细的可以参考：semver.org/lang/zh-CN/…