Skip to content

Latest commit

 

History

History
53 lines (28 loc) · 2.44 KB

File metadata and controls

53 lines (28 loc) · 2.44 KB

当前规划版本

  • [0.1]

    • 新加的功能

      1. 流水线支持Stage
      2. 流水线支持rerun
      3. 支持Job级别的rebuild功能
    • 优化的功能:

      1. 日志组件优化

已发布版本


版本号含义介绍

  1. release版版本号格式:主版本号.次版本号.修订号

    • 主版本号:系统架构有大的调整或对外提供的API不保证兼容的时候需要增加主版本号。
    • 次版本号:当有重大功能发布并且所有的API都能做到向下兼容的时候需要增加次版本号。
    • 修订号:当当前版本的已知问题已修复并且所有的API都能做到向下兼容的时候需要增加修订号。
  2. 先行版版本号格式:主版本号.次版本号.修订号-语义字段.发布次数

    • alpha:版本第一次发布并处于内部测试阶段,此版本仅能用于内测,不可以用于生产环境。
    • beta: 此版本为经过内测的版本,可以用于体验环境部署、功能评测或生产环境总在不影响业务的前提下做小范围灰度验证测试。
    • 发布次数:表明当前版本第几次发布。

版本迭代的规则

  1. 以1.0.1版本为例进行版本迭代讲解
  2. 第一个版本统一由主分支(master)发布,版本号为 1.0.1-alpha.1,并给代码打同名的tag。
  3. 1.0.1-alpha.1版本在测试中如果发现问题并需要进行修复的,修复后需要重新进行发布,并升级发布次数1.0.1-alpha.2,新的alpha版本需要重新进入测试环境做回归测试。不断重复这样的过程直至达到可以发布beta版本的标准为止。
  4. 假设最终1.0.1-alpha.2版本通过了内部所有的测试。那么此版本的代码需要经过代码评审人员的评审确认是否有致命bug/兼容问题/特殊异常,通过内部所有测试且经过评审的版本的代码可以被认为是达到了发布beta的版本的标准,此时需要将版本号标记为1.0.1-beata.1,并将对应的代码打上tag。
  5. 发布的beta版本,可以用来做体验,或在生产环境在不影响业务的前提下做小范围的做灰度验证,如果遇到致命bug/兼容问题/特殊异常等影响功能和稳定性的问题,那么需要回归处理并重复1~3步骤的内容,直到版本不存在致命bug/兼容问题/特殊异常后将其作为release版本发布。
  6. release版本的发布版本号不需要包含语义字段。