Version Management and Upgrades

Version Numbering

• Version numbering uses x.y.z format (where x, y, z are integers).
• Mostly, we follow the semantic versioning scheme.
• x.y is a release branch name.
• x.y.z is a release tag name.
• When releasing x.y.0:
  • Create a new x.y branch, do all bugfix/hotfix there, and make x.y.z releases there.
  • All fixes in the x.y branch must be merged back to master and develop.
  • Change the version number of master to x.(y+1).0a1
  • There is no strict rules about alpha/beta/rc builds yet. We will elaborate as we scale up.
    Once used, alpha versions will have aN suffixes, beta versions bN suffixes, and RC versions rcN suffixes where N is an integer.
• New development should go on master and develop branches.
  • master: commit here directly if your changes are a self-complete one as a single commit.
  • develop: for long-running incomplete development.
  • Use both short-lived and long-running feature branches freely, but ensure there names differ from release branches and tags.

Upgrading

You can upgrade the installed Python packages using pip install -U ... command along with dependencies.

If you have cloned the stable version of source code from git, then pull and check out the next x.y release branch. It is recommended to re-run pip install -U -r requirements.txt as dependencies might be updated.

For the manager, ensure that your database schema is up-to-date by running alembic upgrade head. Also check if any manual etcd configuration scheme change is required, though we will try to keep it compatible and automatically upgrade when first executed.