Release Procedure

Dependencies

Many of the projects use Fabric to automate as much of the process as possible. Fabric is a command line tool (fab) that runs short tasks written in Python from a file fabfile.py in the root of the project. You can install Fabric with pip: pip install fabric

A personal GPG key, one that will be picked up if you run gpg -s
PyPI
- New users create an account on PyPI
- Existing owner adds the required permission for that user on the package's settings page
readthedocs.org
- Create an account and an OpenXC maintainer add your as a maintainer to the openxc-python and vi-firmware docs. The released docs are updated automatically whenever you push to 'master' even if you don't have access to the readthedocs account, but it'd be good to have access.

Use semantic versioning
Prefix the Git tag with v, e.g. v1.0.0
After making a release, bump tag one patch level (e.g. v5.0.0 to v5.0.1) and add a -dev suffix, e.g. v5.0.1-dev

Merge all unmerged and working feature and bugfix branches into next
Run the test suite
Update the changelog, review the Git log to find the major changes
- This is a handy git function to view the changes: https://github.com/peplin/dotfiles/blob/master/git/functions/glog
  - Just run git log master..next to see the new commits
- Preface any breaking changes that force a major API level bump with BREAKING CHANGE:

Bump the version using semantic versioning in
- CHANGELOG.mkd
- README.mkd
- openxc/version.py
- docs/index.rst
- the GENERATED_CODE_VERSION in openxc/generator/coder.py should match the released version of the vi-firmware repo
Checkout master, merge next into master
run fab release, say yes to the tag and use the format v0.9.1
- This will run the test suite, tag, push to GitHub and upload a new release to the Python package index
Checkout the next branch, and edit the same files to change the version to the next development release (one patch release up with the -dev suffix, e.g. v0.9.2-dev