Releasing

Releasing

Table of contents

• When do releases happen
• How to make a release
  • Notify translators
  • Pull translations in
  • Collect included changes
  • Draft the release
• Testing the release
• Publish the release
• Who has the release power

When do releases happen 🚂 🚋 🚋

Releases follow a set weekly schedule. The release manager in charge will draft the release on Thursday, then it will be ready for testers to do their magic and give their approval until the release manager will publish it on Monday. Then, we deploy on Tuesday.

How to make a release 🗒️ ✅

• Create a New Release Issue.

Pull translations in

Check for a Transifex pull request and merge it.

Download all current translations from Transifex with the Transifex client and add them to the master branch.

⚠️ Make sure you don't have local uncommitted changes! You can run git checkout . to discard changes.

git checkout master
git pull upstream master
tx pull --force
git commit -a -m "Update all locales with the latest Transifex translations"
git push upstream master

Draft the release

Draft a new release in the Github UI. Base the release on the commit with the last merged PR you want to include ('Target->Recent Commits') and not master. There's always a chance new PR's are merged between the draft is created and the actual release is published, so this makes the release consistent. If you take a look at the master branch in Semaphore, you should see the Transifex commit you just made in the steps above (named "Update all locales with the latest Transifex translations").

Collect a list of included changes in the release description. The quickest way is to use GitHub's Generate release notes button, otherwise you can refer to the old manual method.

Make sure the notes can be understood by humans. List all user-facing changes first under their own headline. Then list the rest of the changes. Mention any dependencies on ofn-install as well. Copy the user-facing changes to the #instance-managers Slack channel so that they can let people know.

A lot of releases contain only minor bug fixes and tech updates. We then increase the patch version number (1.0.x). If there are significant user-facing changes, we bump the minor version number (1.x.0). The major number is only updated for very big changes like the Spree upgrade from v1 to v2.

Update the Github issue

Add a link to the Semaphore build for the target commit of the new release, and a link to the release draft itself into the release's Github issue so the release tester has a nice time ❤️.

Testing the release

Releases require some testing to ensure critical paths of the application keep working. Talk to one of the testers available to coordinate this (message in the #testing channel). Once the release's draft is finished and she is aware, you can stage the target commit via the Semaphore build page to a server with PayPal and Stripe integrations set up. These need to be tested.

Keep in mind that any merges done to master while the release is in draft won't get tested (unless the release is redrafted with a new target commit and the new build is staged).

Publish the release

Wait for testers to give the ok to publish the release; that will create a git tag for you. Check the Testing the release section above for details.

Announce in #global-community you just published a new release. Use the template below 👇 :

Hi all, just letting you know that we just released [version number] :tada:.
You can read more about it here: https://github.com/openfoodfoundation/openfoodnetwork/releases/tag/[version number]

Nudge the next person to release.

Who has the release power ⚡ 💪

All Ha-Ri certified/core devs will now do releases on a rotating basis.

Deployment

We usually deploy a release for all instances on Tuesdays after publishing the release on Monday.

You can deploy to all production servers with:

ansible-playbook playbooks/deploy.yml --limit all-prod -e "git_version=[release tag]"

The first time you do this, you'll need to make sure that you can ssh into all the production servers without being prompted to confirm the authenticity of the host. I (Andy) did this by ssh'ing to each one and manually typing 'yes' at the prompt.

⚠️ Make sure you don't have local uncommitted changes!

After you deployed, let the instance managers know so that they can run some basic tests. Include a link to the release notes page so that they can easily see what has changed. Post on #instance-managers slack channel:

@channel The new release has been deployed to all instances managed by the global team.
It's time for your after-deploy checks. You can see what was in the release here:
https://github.com/openfoodfoundation/openfoodnetwork/releases/latest