基本原则

语义化版本将会广泛地使用在内部几乎所有需要发布版本的场景，包括但不限于：

• Flutter和小程序的客户端版本，必须遵循语义化版本规则。

• Python和Flutter库，其中Flutter库必须遵循。

• 文档、教程、内部手册等所有文档类。这意味着每一个人都要熟悉语义化版本的规则。

0.1.0版本号的分界线

（已弃用规则）

官方文档建议以0.1.0为初始版本，我们这里进一步规范0.1.0版本要在我们的生产环境上稳定可用（最好是高可用），最少要在生产环境做过可用性验证。0.1.0是我们内部允许同步到GitHub开源的最小版本，必要的项目可以考虑从某个发布开始对外开源以获得社区支持。0.1.0也是我们给企业客户提供此库的开源版本直接安装的服务（通常以GitHub开源形式）或者基于此库构建应用的最小版本要求，在此之前一定要进行尽可能充分的验证，包括单元测试、集成测试等规范测试，以及生产环境验证等等。我通常采用0.0.1为初始开发版本，并且发布一系列0.0.x的小版本来验证生产上的可用性。在0.1.0版本前，鼓励经常性的整体重构甚至推倒重来；到0.1.0版本，项目应当在整体架构上形成初步稳定的思路，不过依然鼓励部分重构甚至必要的整体重构。

1.0.0版本号的分界线

官方文档规定的1.0.0为API稳定的分界线，我们这里进一步严格规定1.0.0版本必须是社区无大的更新（比如腾讯云或微信系产品自己更新了API，或者Flutter更新了大版本或者要求兼容null safety等）的前提下，我们的开源库API必须已经保持稳定，并且最好是核心feature也保持稳定。这一阶段同样是可以开始大规模投入资源宣传、建设开源项目生态等需要API稳定为前提且投入资源高的事情。

TODO

以上规定的目的是形成相对一致的版本风格，防止出现大版本号过多的情况。不过过于严格的规范容易造成小版本号过多的问题，充满break changes的0.x.x版本显然不方便使用语义化版本的各种规则。因此，下一步我们还需要为每个计划发布版本的库大概制定一个0.1.0的目标和1.0.0的目标，以方便我们规划各个库的版本发布计划。