分支跟随 feature ，发版的时候打版本 tag

自豪版本.默认版本.羞愧版本 ---|--当你为发布感到自豪时进行 ---------------|---只是正常的/可以发布的版本 ----------------------------|----修复问题时尴尬到无法承认

还是使用日期吧，比较容意理解，比如 f025.08.16

@TigerK 哈哈，简单粗暴，就是不够优雅

@wKong753900 个人感觉最易懂的才是最优雅的，搞得人看不懂的看起来高大上实则没意义

@wKong753900 语义版本有对应的 git 插件 gitversion 可以自动生成版本

@wKong753900 有流程在这 需求都是从产品的需求池提出来产品经理拍板的组成新版本 各小组评审过的 平时产品经理乱来代价就变高了 不排除老板和产品经理突然的紧急新需求 2.1.0 正在开发 需求 1 需求 2 分配（生产力 1 生产力 2 生产力 3 ） 突然市场上微信做出红包了 新生成紧急 需求 3 红包玩法 2.2.0 待开发 需求 3 产品需要召开项目全组员进行变更 原 2.1.0 变更为 2.3.0 生产力不足我们一般暂停版本 2.1.0 2.2.0 分配（生产力 1 生产力 2 生产力 3 ） 开发 需求 3 生产力充足我们两个版本一起开发 2.2.0 分配（生产力 1 生产力 2 ） 开发 紧急需求 3 2.3.0 分配（生产力 3 ） 开发 需求 1 需求 2 2.2.0 上线后 2.2.0 分支代码合并 2.3.0 生产力释放 又可以全力开发版本 2.3.0 2.3.0 分配（生产力 1 生产力 2 生产力 3 ） 开发 需求 1 需求 2

@xiuming 这么规范

@huangzhiyia 哈哈

理想中是 SemVer 实际上是 1.0.z z++