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 (sfm-twitter-harvester, sfm-flickr-harvester, sfm-weibo-harvester, warcprox, sfm-web-harvester, sfm-ui, sfm-elk) that has changed:
   1. Decide on version increment. Each component will have its own version number.
   2. Change the version of sfm-utils, warcprox, or others in requirements/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. Update the versions of the components in docker/prod/processing/Dockerfile and commit.
   4. Bump the version (as described above).
   5. In a test environment, instantiate containers using prod.docker-compose.yml and test. Note that you may have to wait for Docker Hub to build the images for the component releases.
   6. 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.