发版节奏
- 依据每个端的特点，差异化管理每个端的发版时间。
- 未来开发中，所有需求去追赶固定的发版时间，而不是推发版时间。
- 每周四作为各个端连动发版时间点。
- 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
