Releasing
- When do releases happen
- How to make a release
- Testing the release
- Publish the release
- Who has the release power
Releases follow a set weekly schedule. They get drafted by the release manager in charge every Thursday, then it will be ready for testers to do their magic and give their approval until Monday when the release manager will publish it. Then, we deploy on Tuesday.
See the reasoning behind this process in Release testing next steps and the conversations raised by Maikel and Luis.
I feel obliged to share the gif @lin-d-hop and @RachL found. Remember, Tuesday is the day our users we'll receive our ❤️
Create a New Release Issue.
This is now automated with Slackbot 👍
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.
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 masterIdentify all pull requests that got merged since the last release.
- Option 1: You can look at the last release and use the date of the pinned commit to filter pull requests putting the date and time into the filter box like this:
is:pr merged:>2020-01-16T21:37:00+01:00 sort:updated-desc base:master - Option 2: You can list all pull requests with git and open them in your browser:
git fetch upstream git checkout upstream/master latest="$(git tag --sort="v:refname" | tail -1)" git log "$latest.." --merges --oneline | grep -oP 'Merge pull request #\K[0-9]+(?= from)' | while read n; do echo "https://github.com/openfoodfoundation/openfoodnetwork/pull/$n"; done | xargs firefox
Get the release notes from each of these pull requests. If no release notes are specified you can just copy the pull request title. We only include PRs that have been merged into master.
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").
Make sure the notes can be understood by humans using the types of changes specified by Keep a changelog and use only the sections that have at least one PR in it. Keep in mind these notes are the source of truth for everyone: devs, product people and users. Mention any dependencies on ofn-install as well.
Unless agreement has been reached in the #dev Slack channel that a major release is appropriate, releases only bump up the minor version (eg: from 1.16.0 to 1.17.0).
Add a link to the target commit for the new release, a link to the newly deafted release, and a link to the Semaphore build for that commit into the Github issue for the release so the release tester has a nice time ❤️.
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 we stage again. We don't have a specific release branch; we just have master and tag release versions to pinned commits in it.
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.
All Ha-Ri certified/core devs will now do releases on a rotating basis.
We usually deploy a release for all instances straight away. Check the current Deployment status page for details. 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.
It's time for your after-deploy checks. You can see what was in the release here:
< add the link to the release notes >