Before making a new release, run through this checklist:

• Are any dependencies missing?
• In general dependencies should be locked down to there minimum required version. Thus we ensure that Menpo runs but allow a version to be future proof as new minor versions are released. However, major version constraints should be added, so prefer >=0.16,<1.0 rather than merely >=0.16. For projects that do not properly follow semver, it may be necessary to pin to minor numbers e.g. 0.16.*
• Our dependencies may have made new releases - do we want to bump to the new version? If so is there a conda build for it on all our supported platforms? Make a PR with the dependencies increased and check all our CI tests pass.
• Are there any errors/warnings when you build the documentation?
• Have you updated the changelog?

• For all the above changes to meta.yaml ensure the exact same depenendencies are expressed in setup.py and docs/rtd_environment.yml. For more info on the latter, see #672

versioneer will handle properly versioning the project, so we just need to ensure the master branch is bug free and then tag it.

1. Add a release candidate tag to the project. The tag should be of the form vMAJOR.MINOR.PATCHrc1 to comply with PEP440. Because our Jenkins OS X build bot refuses to rebuild commits it has already built we need to make an 'empty' commit to tag. To do this, on a development machine run git commit --allow-empty -m "v0.7.1rc1" && git tag -a v0.7.1rc1 -m "v0.7.1rc1" && git push --atomic upstream v0.7.1rc1 master - ensuring that your git version is 2.4 or later. This means we have a commit in the tree for the release, and it is tagged with the version string. This tag will be built using only non-master (stable) conda dependencies just like the real release. Use this as a dry run to check there are no nasty surprises. If there are, fix them in subsequent commits (always making an empty commit for further releases).
2. Once the RC is building successfully, we need to tag a new Menpo release. Create a second tag on a development machine using a similar command to before: git commit --allow-empty -m "v0.7.1" && git tag -a v0.7.1 -m "v0.7.1" && git push --atomic upstream v0.7.1 master. With this done, create a new menpo release here

• Choose the existing tag you made which should be of the form vMAJOR.MINOR.PATCH after the semantic versioning system. See the versioning guide for more information about our versioning strategy.
• Making this release will trigger builds on AppVeyor and Travis that will generate conda binaries for all our supported platforms. Once these builds finish conda install -c menpo menpo will provide the new binaries.

3. Upload the new package version to PyPi: python setup.py sdist upload
4. Create a new menpo-notebooks release here
   • The tag name should match the menpo tag name

If this is only a minor release of menpo (e.g. a bugfix) then there may be no need to make a new release of our subprojects. If it's a more major change you will probably also want to make new releases for menpo3d, menpodetect and menpofit. For each project, follow the same process as outlined here, including making RC builds.

4. Update the submodules in website to point to the new tags for menpo and menpo-notebooks
   • Run make in the website repo root to rebuild the website
   • Check the website locally
     • Run python -m SimpleHTTPServer inside the static_website_output folder
     • Navigate to localhost
     • Check new notebooks and new documentation have been generated with the new tag name
5. Commit the new changes and push the static_website_output to upload the website.
6. Celebrate your new release

will vend the new binaries. However, we also mark the release with a github release.

Note that in order to build the website you will need the some extra dependences installed:

>> pip install -r ./docs/requirements.txt