Problem: RELEASE_PROCESS.md doesn't follow BEP-1 (#2161)
Solution: Update RELEASE_PROCESS.md to use only the `master` branch to use Git tags (never branches) to identify new versions.
This commit is contained in:
Troy McConaghy
vrde
parent
42f9160f46
commit
3000e52795
|
|
@ -1,73 +1,61 @@
|
|||
# Our Release Process
|
||||
|
||||
The release process for BigchainDB server differs slightly depending on whether it's a minor or a patch release.
|
||||
## Notes
|
||||
|
||||
BigchainDB follows
|
||||
BigchainDB follows
|
||||
[the Python form of Semantic Versioning](https://packaging.python.org/tutorials/distributing-packages/#choosing-a-versioning-scheme)
|
||||
(i.e. MAJOR.MINOR.PATCH),
|
||||
which is almost identical
|
||||
to [regular semantic versioning](http://semver.org/)
|
||||
except release candidates are labelled like
|
||||
`3.4.5rc2` not `3.4.5-rc2` (with no hyphen).
|
||||
to [regular semantic versioning](http://semver.org/), 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
|
||||
|
||||
## Minor release
|
||||
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.
|
||||
|
||||
A minor release is preceeded by a feature freeze and created from the 'master' branch. This is a summary of the steps we go through to release a new minor version of BigchainDB Server.
|
||||
We follow [BEP-1](https://github.com/bigchaindb/BEPs/tree/master/1), which is our variant of C4, the Collective Code Construction Contract, so a release is just a [tagged commit](https://git-scm.com/book/en/v2/Git-Basics-Tagging) on the `master` branch, i.e. a label for a particular Git commit.
|
||||
|
||||
1. Update the `CHANGELOG.md` file in master
|
||||
1. 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.) Commit that change to master
|
||||
1. Create and checkout a new branch for the minor release, named after the minor version, without a preceeding 'v', e.g. `git checkout -b 0.9` (*not* 0.9.0, this new branch will be for e.g. 0.9.0, 0.9.1, 0.9.2, etc. each of which will be identified by a tagged commit)
|
||||
1. Push the new branch to GitHub, e.g. `git push origin 0.9`
|
||||
1. Create and checkout a new branch off of the 0.9 branch. Let's call it branch T for now
|
||||
1. In `bigchaindb/version.py`, update `__version__` and `__short_version__`, e.g. to `0.9` and `0.9.0` (with no `.dev` on the end)
|
||||
1. Commit those changes, push the new branch T to GitHub, and use the pushed branch T to create a new pull request merging the T branch into the 0.9 branch.
|
||||
1. Wait for all the tests to pass! Then merge T into 0.9.
|
||||
1. Follow steps outlined in [Common Steps](#common-steps)
|
||||
1. In 'master' branch, Edit `bigchaindb/version.py`, increment the minor version to the next planned release, e.g. `0.10.0.dev`. (Exception: 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).
|
||||
1. Go to [Docker Hub](https://hub.docker.com/), sign in, go to bigchaindb/bigchaindb, go to Settings - Build Settings, and under the build with Docker Tag Name equal to `latest`, change the Name to the number of the new release, e.g. `0.9`
|
||||
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.
|
||||
|
||||
Congratulations, you have released BigchainDB!
|
||||
## Steps
|
||||
|
||||
## Patch release
|
||||
1. Create a pull request where you make the following changes:
|
||||
|
||||
A patch release is similar to a minor release, but piggybacks on an existing minor release branch:
|
||||
|
||||
1. Check out the minor release branch, e.g. `0.9`
|
||||
1. Apply the changes you want, e.g. using `git cherry-pick`.
|
||||
1. Update the `CHANGELOG.md` file
|
||||
1. Increment the patch version in `bigchaindb/version.py`, e.g. `0.9.1`
|
||||
1. Commit that change
|
||||
1. In `k8s/bigchaindb/bigchaindb-dep.yaml` AND in `k8s/dev-setup/bigchaindb.yaml`, find the line of the form `image: bigchaindb/bigchaindb:0.9.0` and change the version number to the new version number, e.g. `0.9.1`. (This is the Docker image that Kubernetes should pull from Docker Hub.)
|
||||
1. Commit that change
|
||||
1. Push the updated minor release branch to GitHub
|
||||
1. Follow steps outlined in [Common Steps](#common-steps)
|
||||
1. Cherry-pick the `CHANGELOG.md` update commit (made above) to the `master` branch
|
||||
|
||||
## Common steps
|
||||
|
||||
These steps are common between minor and patch releases:
|
||||
- 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](https://pypi.python.org/pypi?%3Aaction=list_classifiers).
|
||||
|
||||
1. **Wait for all the tests to pass!**
|
||||
1. Merge the pull request into the `master` branch.
|
||||
1. Go to the [bigchaindb/bigchaindb Releases page on GitHub](https://github.com/bigchaindb/bigchaindb/releases)
|
||||
and click the "Draft a new release" button
|
||||
and click the "Draft a new release" button.
|
||||
1. Fill in the details:
|
||||
- Tag version: version number preceeded by 'v', e.g. "v0.9.1"
|
||||
- Target: the release branch that was just pushed
|
||||
- Title: Same as tag name above, e.g "v0.9.1"
|
||||
- Description: The body of the changelog entry (Added, Changed, etc.)
|
||||
1. Click "Publish release" to publish the release on GitHub
|
||||
1. Make sure your local Git is in the same state as the release: e.g. `git fetch <remote-name>` and `git checkout v0.9.1`
|
||||
1. Make sure you have a `~/.pypirc` file containing credentials for PyPI
|
||||
1. Do a `make release` to build and publish the new `bigchaindb` package on PyPI
|
||||
1. [Login to readthedocs.org](https://readthedocs.org/accounts/login/) and go to the **BigchainDB Server** project (*not* **BigchainDB**), then:
|
||||
- **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.)
|
||||
1. Click "Publish release" to publish the release on GitHub.
|
||||
1. 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.
|
||||
1. Make sure you have a `~/.pypirc` file containing credentials for PyPI.
|
||||
1. Do `make release` to build and publish the new `bigchaindb` package on PyPI.
|
||||
1. [Log in to readthedocs.org](https://readthedocs.org/accounts/login/) 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.)
|
||||
(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 new version's branch
|
||||
(without the 'v' in front) is _not_ active.
|
||||
3. Make sure the **stable** branch is _not_ active.
|
||||
4. Scroll to the bottom of the page and click the Submit button.
|
||||
1. Make sure the **stable** branch is _not_ active.
|
||||
1. Scroll to the bottom of the page and click the "Submit" button.
|
||||
1. Go to [Docker Hub](https://hub.docker.com/), 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).
|
||||
|
|
|
|||
Loading…
Reference in New Issue