Release process

New development should be done on master and always with the next release's version number in all docs and configuration files. Once ready to test the migration/install:

Release script

1. Verify all unit tests pass
2. Verify it works in supported browsers
3. Create a release branch: git branch x.y.z
4. Check it out: git checkout x.y.z
5. Push it upstream to deploy off of: git push origin x.y.z
6. Write/test/commit migration script
7. Add upgrade documentation to docs/upgrades.rst
8. Verify any new translations. See below.
9. If any languages have been added, update jumpstart/views.py and docs/i18n.rst to list them
10. Generate an AMI for the release (remove ~/setup_panda.sh and PANDA public SSH key before imaging)
11. Make new AMI public
12. Clone the new AMI to every EC2 region. (Note: NEW PROCESS. TEST WELL.)
13. Update docs/amazon.rst with new AMI id's.
14. Update docs/index.rst to remove development version disclaimer
15. Switch back to the master branch: git checkout master
16. Merge in changes from the release branch: git merge x.y.z
17. Push changes upstream: git push
18. Flag x.y.z version branch for doc building on RTFD and mark it as the default
19. Update to next version number in setup_panda.sh
20. Update to next version number in docs/conf.py
21. Update to next version number in config/settings.py
22. Update to next version number in CHANGELOG
23. Update docs to reference the next version number in URLs
24. Add new development version disclaimer to docs
25. Commit next version: git commit -am "Rev to version a.b.c for development."
26. Push next version upstream: git push
27. Make release announcements on the mailing list and Twitter

Verifying new translations

1. Ensure "AND" and "OR" are not translated when referring to Solr keywords.
2. Ensure plurals are in .po file as separate messages strings.