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 and then sfm-twitter-harvester, sfm-flickr-harvester, sfm-weibo-harvester, sfm-tumblr-harvester, sfm-web-harvester, sfm-ui, sfm-elk:
   1. Change the version number in configuration files by executing bumpversion <major or minor or patch.
   2. Change the version of warcprox or others in requirements/requirements.txt if necessary.
   3. 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.
4. For sfm-docker:
   1. Update SFM_VERSION in example.env` and commit.
   2. 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.
   3. 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.
   4. 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.