非公开版本

本文用于约定非公开版本0.Y.Z的使用方式。

基本规定：

中版本号定义特性，小版本号约定API。项目均采取所有0.x版本默认互不兼容，必须指定版本号使用的策略。

对于1.x需要依赖0.x这种可能存在的情况，采取优先稳定底层依赖API并发布1.0再考虑上层库的处理原则。

1. 开源项目

该类项目增加每次break change必须添加相应中版本号的规定。

2. 非开源项目

遵循基本规定。

我们的理由

Dart库对v0.x版本的定义是0.x.y+z，以类比x.y.z。Dart对依赖版本有一套明确的处理规范，所以需要公开发布的Dart和Flutter库的0.x版本遵循这个约定。

但是我们的大部分版本规划都是以产品特性为单位规划的，目的是便于统一并协调内部各个项目的进度。

课程平台目前采取中版本统一、小版本各个仓库独立的策略。例如，v0.1版本约定为提供课程资源访问，Flutter、Django、API文档、PRD文档分别有自己的小版本。这些小版本的更新往往是不兼容的，因此在release note需注明这个版本对上一个版本不兼容。

如果采取上述Dart库的策略，既有的版本管理将会变得复杂。目前的开发过程中，一个特性的增加往往意味着字段反复修改等细节处理以及频繁的重新设计和重构。也就是说，目前的开发情况是只要发布版本，几乎都会发生不兼容更新。所以上述Dart库的规范对目前的开发来说没有太大意义。

因此放弃Dart库推荐的理解，而采取自有定义成为我们的选择。中版本号定义特性，小版本号约定API。我们放弃Dart库和Python库的版本兼容，采取所有0.x版本默认互不兼容，必须指定版本号使用的策略。

考虑到我们目前大部分项目都是0.x，还不存在1.x需要依赖0.x这种意外情况，因此暂不考虑。对于这类问题的解决办法，我们主要考虑优先稳定底层依赖API并发布1.0，然后再考虑上层库。因此，各个库的1.0版本的约定对于我们来说十分重要，关系到项目和项目之间的协作。