产品版本管理
背景
后续各产品都会更强调平台属性，大部分二位版本迭代的功能都将是平台级功能。因此，二位版本的迭代不太可能以双周这种形式来发布一个大版本，肯定是以2~3个月为周期的迭代。
目的
版本号定义
其中，第一、二、三位版本号为主版本号，客户可见。第四位是 build号，对客户不可见。
第一位版本号
- 意义：第1位升级+1（后续统称为升级），意味着公司产品战略升级。
- 需求范围：需求由公司战略层确定，基于公司战略进行拆解。
- 递增规则：基于公司产品战略层面的定义，第一位版本号从 0 递增。
第二位版本号
- 意义：
- 需求范围：需求来自市场需求调研、竞品分析、以及销售/交付侧等反馈的问题。以提升客户价值和产品能力为目标，通过产品规划和决策明确需求边界。
- 交付标准：需要对客户交付。
- 递增规则：按功能预先制定，第二位版本号从 0 递增。
- 发布周期：。
- 分支管理：有其特定的 release、test 和 bugfix 分支。
需求范围确定要求：
第三位版本号
- 意义：第3位升级，意味着该版本有满足部分客户的需求，具备针对部分客户升级交付的能力。
- 需求范围：需求来自2 位版本产品规划中重点功能特性的计划安排，以及客户临时反馈的问题。以按期落地产品功能和响应客户临时反馈需求为目标，通过产品项目决策明确项目需求范围。需求范围由 PM 、RD 和 QA 一起确定。
- 交付标准：给需要的客户交付；其他客户不交付。
- 递增规则：按迭代发版，第三位版本号从 0 递增。
- 发布周期：Alpha 阶段客户升级时发版；Beta 阶段双周迭代有新功能时发版。
- 分支管理：历史版本无固定分支；最新版有开发分支。
需求范围确定原则
- 迭代需求确定后，新来需求默认作为下个迭代的需求池；
- 确定的 P0 需求，可临时插入迭代；
- 影响客户体验的新功能要支持灰度发布。
成熟的二位版本上发布新功能
-
- 灰度功能：新功能若会影响客户体验，需增加灰度功能开关。灰度功能
第四位 build 号
- 意义：
- 需求范围：需求来自于客户或内部反馈的 bug 及功能缺陷。需求范围由 RD 和 QA 确定。
- 交付标准：不需要对客户交付。
- 递增规则：每次打包时递增，在小版本内从 0 递增。
- 发布周期：一般。
升级规则
- 第1\2位版本号（主版本号）变更只能进行中版本升级
- 主版本号及三位版本号判断大小关系只能向前升级,不能降级
- 第3位版本号升级不允许变更依赖关系，不允许增加减少模块，不允许修改modules.yml，不允许执行自定义升级脚本，不允许创建资源
- 第4位版本号（Build号）变更只能进行小版本升级，Build号不判断大小关系,可指定任意版本覆盖升级
版本成熟度
在第二位版本号上定义版本的生命周期。
Alpha 阶段
- 意义：内部测试阶段。此阶段会发布重要功能，会在公司大群发布通知，进行内部试用。
- 生成：新的中版本生成后，标记 alpha 阶段。
- 客户升级：可供客户使用（客户可用，但有风险）
- 在客户要求的情况下为其升级：Alpha 状态客户体验时，将 PM、QA、RD 拉到客户群中，进行客户服务；
- 重要功能可找种子客户试用：重要功能完成后，需要做功能交付。
备注：客户使用前需要做小范围产品兼容性测试。
Beta 阶段
-
意义：外部体验阶段。规划的重要功能已发布，此阶段主要是bugfix，可根据反馈、发布小功能。
- Alpha → Beta： 版本中规划的重要功能研发完成后，进入 Beta 状态。
- 客户升级：会主动推客户升级使用。
- 内部交付：转 Beta 阶段，需要 PM 向客户成功与分析师团队交付，小动物提供客户支持。
GM 阶段
- 意义：版本成熟阶段。仅做 bugfix，一般不增加新功能。
- Beta → GM：版本封版。版本中不再增加新功能。
- 客户升级：可大规模推广的版本。新客户优先升级 GM 版。
其他
- Alpha → Beta → GM 是单向流程，不会回退。GM 阶段若新增功能后，版本仍然是 GM 状态，不会回退到 Beta。
长期维护（LTS）版本
-
定义：会大规模推广的版本。在第二位版本号上提前规划。
- 周期：每隔一个二位版本，发布一个 LTS 版本。周期约半年。
- 升级：新的 LTS 版本发布后，原 LTS 版本客户会升级到新的 LTS 版本。
其他：产品研发团队只会维护一个 LTS 版本。
