需求版本控制

发版节奏

• 依据每个端的特点，差异化管理每个端的发版时间。
• 未来开发中，所有需求去追赶固定的发版时间，而不是推发版时间。
• 每周四作为各个端连动发版时间点。
• iOS/Android 固定版本时间。
• server 和 h5 紧急问题可以临时发版本，但必须由管理层决定。

核心业务服务

image.png

• 周四： 与客户端连动发版（如果与客户端无关系，就进行内部发版）。
• 周二： 服务器内部发版，不影响客户端。
• 周一、周三、周五： 在经过管理层允许情况下开放紧急发版。

iOS/Android

image.png

• C端两周一个版本（第二周周四）
• B端一周一个版本（每周周四，没有特殊内容可以不发）

H5

image.png

• 每天一个版本（没有内容可以不发），每周周四作为与客户端或服务端连动版本

版本号

版本号管理策略： X.X.X.[Y]

• 第一位X：主版本号
  当项目进行了重大修改或局部修改累计较多，而导致项目整体发生全局变化时，主版本号加1，其他位归0
• 第二位X：次版本号
  当项目在原有的基础上增加了重要新功能时，主版本号不变，子版本号加1，修正版本号归0
• 第三位X：修正版本号
  当项目进行了局部修改或bug修正时，主版本号和次版本号不变，修正版本号加1
• 第四位Y：
  a)当服务端或H5（不涉及客户端）进行发版时，在当前三位版本号的基础上启用第四位，例如1.2.3.1
  b)当客户端进行紧急bug修复时，启用第四位

固定版本号

• 版本号以周二和周四两个时间点设定，未来的版本号以此
  类推。
• 不管周二和周四有没有发版都需要设定一个版本号。

需求与版本号绑定流程

• 每个版本对应的需求由专人(暂由梁会锋)管制。
• 产品需求和开发 L 确认后，必须给出明确的发布版本。
• 由开发L和产品负责人一起向郭岩申请加入对应版本（需求与版本号绑定）。 郭岩将维护每个版本对应的需求列表。
• 明确发布版本为上线时间，开发结束点和测试验收点都往前推。

image.png