Release process

1. For each component that has changed:
   1. Decide on the version increment (using semantic versioning). Each component will have its own version number.
   2. Create any necessary versioned docker image definitions, e.g., "docker/app-prod/0.2.0". (Note that the dockerfile may reference the version tag which will not exist until later in this process.)
   3. Change the version in any configuration files (e.g., setup.py, conf.py or local_settings.py).
   4. Create a github release. The tag version should be the version number, e.g., "0.2.1". The tag title should be "v" followed by the version number, e.g., "v0.2.1". Provide release notes as the release description. For now, mark the release as not ready for production.
   5. In Docker Hub, add a new build setting and change the “latest” build setting to reference the new versioned docker image definition for each versioned docker image definition. When completed, trigger a build.
2. For sfm-docker:
   1. Decide on the version increment, incrementing for the largest change of any component.
   2. Update the versions of the components in prod.docker-compose.yml and commit.
   3. In a test environment, instantiate containers using prod.docker-compose.yml and run smoke tests.
   4. Create a github release, following directions above. The release notes should provide an overview of the release, as well as linking to the release notes of all changed components.
3. Deploy the release to production and run smoke tests.
4. Announce the release on sfm-dev list.