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

We switched back to 4-digit version policy per discussion in July 2016: mail archive: http://mail-archives.apache.org/mod_mbox/incubator-hawq-dev/201607.mbox/%3CCAE44UQcymo%3D8rBhE8b5bQ3qV-wH8Bvi0WXC89bqJgj%2Bh7Rzw9g%40mail.gmail.com%3E

 

Branching strategy

Goals

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

Branching

  • 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. Goden Yao

    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.