Skip to content

Latest commit

 

History

History
38 lines (27 loc) · 1.88 KB

RELEASE.md

File metadata and controls

38 lines (27 loc) · 1.88 KB
Raw

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