Release Procedure

Cutting a QuantumLeap release.

So here's a quick-quick chop-chop recipe for releasing a new QuantumLeap version.

• Stick to Semantic Versioning for version numbers: M.m.p, where M, m and p are, respectively, the major, minor and patch number—e.g. 0.8.0.
• Branch off from master, branch name: release-M.m.p, e.g. release-0.8.0.
• Update the reporter.version module with the new version number.
• Ditto for the version test and for the API spec, quantumleap.yml.
• Sum up new features, bug fixes, docs, any backward compatibility issues, and so on in RELEASE_NOTES.md. Ideally one bullet point for each item. Keep it short but informative and if possible avoid catch-all statements like "improved DB back-end". (What did we actually make better?) Also make sure to add a reference to the PR where that item was implemented so peeps out there will be able to find out more about that feature or bug fix on GitHub.
• Commit your changes to the release branch above with a commit message of "Release M.m.p"—e.g. git commit -m 'Release 0.8.0'.
• Open a pull request with a title of "Release M.m.p", e.g. "Release 0.8.0". Zap the pre-populated text, copy over the release notes you added earlier, then write a little intro with release highlights and anything worth mentioning. Have a look at the PR for release 0.8.0 for an example. Make sure there are no broken links to the PRs referenced in the release notes you copied over.
• Merge the PR and delete the release branch.
• Go to the GitHub Releases page and hit the "Draft a new release" button. Enter the release version you used earlier in the "Tag version" field and enter "Release M.m.p" (e.g. "Release 0.8.0") in the "Release title" field. Then copy-paste the release intro text you wrote in the PR into the "Describe this release" text area. Also make sure to add a link back to the PR so peeps can click through to see the full release notes. Have a look at Release 0.8.0 for an example.
• Double check the new Docker image got uploaded to DockerHub.
• Update new spec to swaggerhub, and tag it correctly.

Yep, we could streamline and automate some of the steps, but I'll leave that discussion for another day :-)

Now the master branch is ready for the next dev cycle, e.g. 0.8.1. To kick-off the next cycle:

• Branch off from master.
• In the new branch update the reporter.version module with the new version number plus a -dev suffix, e.g. 0.8.1-dev.
• Ditto for the version test and for the API spec, quantumleap.yml.
• Slap placeholders on RELEASE_NOTES.md to remind us we're in a new release cycle. Just add a new section with a title reflecting the dev cycle, e.g. 0.8.1-dev and subsection headers: "New features", "Bug fixes", "Documentation", "Technical debt".
• Open a PR, merge your changes into master and delete the PR branch.

Have a look at the changes in PR 465 for an example.