Release process

1. For sfm-utils:
   1. Decide on whether to increment version by major, minor, or patch (using semantic versioning).
   2. Change the version number in configuration files by executing bumpversion <major or minor or patch and then commit and push.
   3. 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.
2. For each component that has changed:
   1. Decide on version increment. Each component will have its own version number.
   2. Change the version of sfm-utils in requirements.txt if necessary.
   3. Bump the version (as described above).
   4. Create a github release (as described above).
3. 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.
4. Deploy the release to production and run smoke tests.
5. Announce the release on sfm-dev list.