Release process

Starting with version 1.4.1, all core SFM components will have the same version numbers. Previously, different components could have different version numbers.

1. If warcprox has changed:
   1. Decide on whether to increment version by major, minor, or patch (using semantic versioning).
   2. 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. Decide on whether to increment the version of the core components by major, minor, or patch.
3. For sfm-utils (do sfm-utils first!) and then sfm-twitter-harvester, sfm-flickr-harvester, sfm-weibo-harvester, sfm-tumblr-harvester, sfm-ui:
   1. In your virtualenv, pip install bumpversion
   2. Change the version number in configuration files by executing bumpversion <major or minor or patch>. Use a keyword of major, minor, or patch rather than the new version number, e.g. bumpversion minor
   3. Change the version of warcprox or others in requirements/requirements.txt if necessary.
   4. Commit and push.
   5. Create a tag and push the tag to GitHub. The tag version should be the version number, e.g., "2.4.0". git tag -a 2.4.0 -m "2.4.0"
   6. Create a GitHub release. The release title on GitHub should be "Version " followed by the version number, e.g., "Version 2.4.0". Provide release notes as the release description.
4. For sfm-docker:
   1. Change the version number in configuration files by executing bumpversion <major or minor or patch>.
   2. Commit and push.
   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. Deploy to SFM instances. Deployment notes for GW-managed instances (Google Doc).
6. 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.
7. Draft and publish a blog post for the release, highlighting changes and pointing to the release notes for sfm-ui. The blog posts are part of the Github Pages SFM site on the gh-pages branch of the sfm-ui repo.