Release Process

The main branch contains tagged release commits. We follow a simple process in order to release a new version of WFL:

1. Create a release branch based off develop
2. release branch names follow the convention release/X.Y.Z-rc
3. the version string should match that specified in version
4. Identify and cherry-pick additional commits from develop that you want to release (e.g. late features and bug fixes).
5. Create a release candidate and deploy to a testing environment. See instructions bellow.
6. Bash the release candidate. Add/cherry-pick any bug fixes that result.
7. Create a pull request into main. You will need to run ./ops/cli.py release to generate the changelog for this release (the -d flag can be used to do a dry run without writing to the CHANGELOG.mdfile).
8. When the PR is approved, merge it into main. The release action will run automatically to build, test and build and push the tagged docker images of WFL to DockerHub. Please merge PRs that have passed all automated tests only.

Tip

It can take up to 30 minutes for the Github Action to finish! Please be patient!

Tip

Remember to create a PR to bump the version string in version in develop for the next release, including changes to CHANGELOG.md from the release.

Creating a Release Candidate

In this example, we will create a release candidate for vX.Y.Z. We will assume the existence of a release branch release/X.Y.Z-rc. From wfl's root directory:

1. Ensure your local repository clone is clean $ make distclean

2. Prepare sources bash $ git checkout release/X.Y.Z-rc $ git pull origin release/X.Y.Z-rc --ff

3. Build the docker images locally bash $ make TARGET=images

4. Tag the commit and release the images to dockerhub with the release candidate tag. Let us assume that this is the Mth release candidate. bash $ ./ops/cli.py tag-and-push-images --version=X.Y.Z-rcN

Tip

You can run make in parallel by adding -jN to the end of your make command, where N is the number of concurrent jobs to run.