Version policy

4-digit semantic versioning string is used: x.y.z.h

     - "x" means MAJOR version
     - "y" means MINOR version
     - "z" means PATCH
     - "h" hot fixes

MAJOR version change also means catalog changes.


Version History


Branching strategy


  • Keep team focusing on one release at one time
  • Ease CI and improve engineering efficiency


  • Keep all major/minor release work on Master branch
  • When we want to do a major/minor release, create a release branch
  • Branch will also be needed when doing patch releases: 
  • Example: after 2.0, a hot fix on 2.0 is needed, cut a branch 2.0.x from 2.0. Put the fix to 2.0.x, if applicable on Master, put it on master too. Finally, tag 2.0.1 release on 2.0.x





  • No labels

1 Comment

  1. For Branching section:

    If we only tag major/minor release without a release branch, imagine the scenario that while we're waiting for a specific feature commit to tag before the release, other bug fixes, features get committed into the trunk. 

    The tagged the release will involuntarily take all the changes in between, which may increase test cycles and introduce regressions.