bigchaindb/RELEASE_PROCESS.md

Our Release Process

Notes

BigchainDB follows the Python form of Semantic Versioning (i.e. MAJOR.MINOR.PATCH), which is almost identical to regular semantic versioning, but there's no hyphen, e.g.

• 0.9.0 for a typical final release
• 4.5.2a1 not 4.5.2-a1 for the first Alpha release
• 3.4.5rc2 not 3.4.5-rc2 for Release Candidate 2

We use 0.9 and 0.9.0 as example version and short-version values below. You should replace those with the correct values for your new version.

We follow BEP-1, which is our variant of C4, the Collective Code Construction Contract, so a release is just a tagged commit on the master branch, i.e. a label for a particular Git commit.

The following steps are what we do to release a new version of BigchainDB Server. The steps to release the Python Driver are similar but not the same.

Steps

1. Create a pull request where you make the following changes:

   • Update CHANGELOG.md
   • In k8s/bigchaindb/bigchaindb-dep.yaml and in k8s/dev-setup/bigchaindb.yaml, find the line of the form image: bigchaindb/bigchaindb:0.8.1 and change the version number to the new version number, e.g. 0.9.0. (This is the Docker image that Kubernetes should pull from Docker Hub.)
   • In bigchaindb/version.py:
     • update __version__ to e.g. 0.9.0 (with no .dev on the end)
     • update __short_version__ to e.g. 0.9 (with no .dev on the end)
   • In setup.py, maybe update the development status item in the classifiers list. For example, one allowed value is "Development Status :: 5 - Production/Stable". The allowed values are listed at pypi.python.org.

2. Wait for all the tests to pass!

3. Merge the pull request into the master branch.

4. Go to the bigchaindb/bigchaindb Releases page on GitHub and click the "Draft a new release" button.

5. Fill in the details:

   • Tag version: version number preceded by v, e.g. v0.9.1
   • Target: the last commit that was just merged. In other words, that commit will get a Git tag with the value given for tag version above.
   • Title: Same as tag version above, e.g v0.9.1
   • Description: The body of the changelog entry (Added, Changed, etc.)

6. Click "Publish release" to publish the release on GitHub.

7. On your local computer, make sure you're on the master branch and that it's up-to-date with the master branch in the bigchaindb/bigchaindb repository (e.g. git fetch upstream and git merge upstream/master). We're going to use that to push a new bigchaindb package to PyPI.

8. Make sure you have a ~/.pypirc file containing credentials for PyPI.

9. Do make release to build and publish the new bigchaindb package on PyPI.

10. Log in to readthedocs.org and go to the BigchainDB Server project, then:

    • Go to Admin --> Advanced Settings and make sure that "Default branch:" (i.e. what "latest" points to) is set to the new release's tag, e.g. v0.9.1. (Don't miss the v in front.)
    • Go to Admin --> Versions and under Choose Active Versions, do these things:
      1. Make sure that the new version's tag is "Active" and "Public"
      2. Make sure the stable branch is not active.
      3. Scroll to the bottom of the page and click the "Submit" button.

11. Go to Docker Hub, sign in, go to bigchaindb/bigchaindb, and go to Settings --> Build Settings. Find the row where "Docker Tag Name" equals latest and change the value of "Name" to the name (Git tag) of the new release, e.g. v0.9.0.

Congratulations, you have released a new version of BigchainDB Server!

Post-Release Steps

In the master branch, open bigchaindb/version.py and increment the minor version to the next planned release, e.g. 0.10.0.dev. Note: If you just released X.Y.Zrc1 then increment the minor version to X.Y.Zrc2. This step is so people reading the latest docs will know that they're for the latest (master branch) version of BigchainDB Server, not the docs at the time of the most recent release (which are also available).