Release steps - consuldemocracy/consuldemocracy GitHub Wiki

Everybody loves releases :smile:, but there are many things to do and it's easy to miss one. Here's a checklist.

  1. Open a pull request updating the CHANGELOG and changing app/controllers/installation_controller.rb. Check pull requests for previous releases for references.
  2. Open a pull request to update Crowdin translations and add it to the CHANGELOG.
  3. Open a draft pull request for the installer to install the new version (in that pull request, use the release branch on the git archive line for now).
  4. Rebase the demo-staging branch against the release branch and deploy it to the staging server.
  5. Create a new release draft. Check previous releases for references. Don't add a tag yet to make sure you don't accidentally publishing it.
  6. Prepare the text of the announcement for our slack channel.
  7. Check there aren't any new patch releases for the current version of Ruby.
  8. Check there aren't any pending security alerts.
  9. Create a temporary branch, make a commit introducing linter erros in Ruby, ERB, JavaScript and CSS files, and check that bundle exec pronto run is working properly.
  10. Once it's approved, merge the pull request to update Crowdin translations.
  11. Once it's approved, update the release date in the pull request that updates the CHANGELOG and merge it.
  12. Rebase the demo branch against the master branch and deploy it to the demo server.
  13. Update the technical documentation so it includes the new release. For non-patch releases, this includes creating a new branch with a docs- prefix. Make sure not to overwrite changes done by people editing the documentation via gitbook.
  14. Check "Create a discussion for this release" in the release draft.
  15. Update the link to the CHANGELOG in the release draft and publish the release.
  16. Edit the release in order to add a link to the release discussion. Check previous releases for references.
  17. Update the git archive line in the pull request to update the installer so it points to the just-generated tag.
  18. Once the tests have passed, merge the pull request to update the installer.
  19. Publish a new release for the installer. The version number should be the same as the version number of the new version of Consul.
  20. Send an announcement to the slack channel, including a link to the changelog, the release notes and the release discussion.
  21. Add a new column to our Kanban project for the next version and automate it.
  22. When deleting an old column from the Kanban project, make sure to click on "delete all" before deleting the column itself (if you don't, you'll have to manually remove every pull request that was in that column one by one).