You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »


Version policy


3-digit version string is used: x.y.z

     - "x" means MAJOR version
     - "y" means MINOR version
     - "z" means PATCH
Increase: 
  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards-compatible manner, and
  • PATCH version when you make backwards-compatible bug fixes.
  • Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

MAJOR and MINOR also mean catalog changes from HAWQ perspective.

 

Branching strategy

Goals

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

Branching

  • Keep all major/minor/maintenance release work on Master branch
  • When we want to do a major/minor/maintenance release, tag it on master branch
  • Branch only when doing patch releases: 
    • Example: after 2.0.0, a hotfix on 2.0.0 is needed, cut a branch 2.0.x from 2.0.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