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 of warcprox or others in requirements/requirements.txt if necessary.
   3. Change the version number in configuration files by executing bumpversion <major or minor or patch and then commit and push.
   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.
2. For each component (sfm-twitter-harvester, sfm-flickr-harvester, sfm-weibo-harvester, sfm-tumblr-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 example.prod.docker-compose.yml and commit.
   3. Create a github release, following directions above. Creating the github release before testing is necessary so that the sfm-processing image is built. Adding the release notes can be delayed until after testing.
   4. In a test environment, instantiate containers using example.prod.docker-compose.yml and test. Note that you may have to wait for Docker Hub to build the images for the component releases.
   5. Add the release notes if not already done. The release notes should provide an overview of the release, as well as linking to the release notes of all changed components.