THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Table of Contents
Version policy
3-digit version string 4-digit semantic versioning string is used: x.y.z.h
- "x" means MAJOR version
- "y" means MINOR version
- "z" means PATCH
Increase:
- "h" hot fixes
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.
change also means catalog changes.
| Info | ||
|---|---|---|
| ||
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 /maintenance release work on Master branch
- When we want to do a major/minor /maintenance release, tag it on master create a release branch
- Branch only will also be needed when doing hotfix patch releases:
- Example: after 2.0.0, a hotfix hot fix 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