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

Required Accounts

• 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.

Versioning

• 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

All projects

• 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:

openxc-android

• Checkout master, merge next into master
• Bump the version using semantic versioning in
  • CHANGELOG.mkd
  • */AndroidManifest.xml
  • */pom.xml
• Run fab release to run tests, tag and make the APK file for the Enabler
• Checkout next, merge in master - bump to next development version.
• TODO merge into private fork which includes Crashlytics API key, then rebuild
• Attach openxc-enabler.apk (from openxc-android/enabler/target - you need to manually add the version to the filename) to the release

openxc-python

• 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

vi-firmware

• Make sure you release the Python library first if there are any updates
• Update script/bootstrap/pip-requirements.txt to use released version at PyPI (i.e. the requirement should be openxc==<latestversion>)
• Bump the version using semantic versioning in
  • CHANGELOG.mkd
  • README.mkd
  • src/config.cpp
  • docs/index.rst
  • docs/conf.py
• Checkout master, merge in next
• Run 'fab release', say yes to the tag and use the format v0.9.1
  • This will run the test suite, tag, and push to GitHub
• 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
• Also change script/pip-requirements.txt back to using the development version from Git: -e git+https://github.com/openxc/openxc-python.git@next#egg=openxc
• Go to https://github.com/openxc/vi-firmware/releases and promote the tag you just created to a new release - copy and paste the changelog into the description.
  • Attach the openxc-vi-firmware-*.zip from the releases directory to the release on GitHub