RELEASE.md

Release process

We follow Semantic Versioning Specification 2.0.0.

In short, given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backward-compatible manner, and
3. PATCH version when you make backward-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Shipping a new version

The release process is mostly automated via Github Actions however, a few manual steps are required:

• Edit package.json version in master branch (e.g. "version": "1.0.0")

• Add, commit, and push the changes to package.json

• Create a new tag from master branch (e.g. git tag v1.0.0, note the v -prefix)

• Push tag to remote (e.g. git push origin v1.0.0)

• Package job is triggered, wait for it to finish

• A new release draft is automatically created via Github Actions

• Edit release draft

  • Make sure the current and previous versions are correct
  • Edit Compatibility section (Correct Netflix/metaflow-service release versions)
  • Edit/remove Additional resources section
  • Make sure the release artifact is uploaded

• Publish release draft

• Follow the metaflow-service release docs to set the UI version and publish to dockerhub

Preview release notes

You can use release-notes.sh locally to preview generated release notes before pushing a tag to remote:

$ ./release-notes.sh v1.0.0