The process below applies to both Meltano and then SDK, unless otherwise noted.
We are always releasing, and we aim to have an evergreen release process, handling the operational release and marketing work simultaneously while performing development.
The release schedule is determined by Product and Marketing. The Engineering team aims to always be ready to ship, with sufficient automation and documentation in place to allow anyone in the company to perform the role of Release Manager.
We have a sliding window of
Release Manager role within the Engineering team, with the prior
Release Manager on call to support the next
Release Manager. If issues arise or a second opinion is needed during release, the last person who ran the release process will perform this supporting function for the next.
Regular releases get a minor version bump (
Releases that only address regressions introduced in the most recent release get a patch version bump (
Current as of: Aug 2022
The processes for releasing the Meltano and the SDK are essentially the same. At a high level they consistent of:
Ctl+Enter does not just save your copy edits for the draft releases - it also publishes the workflow. Extreme caution is advised to not “accidentally” release too early.
The guidelines below will help to confirm that the release notes are a helpful resource for users and contributors.
Note: It’s generally not worth slowing down the release process to update these in the changelog. Our standard is that the CHANGELOG should prioritize being accurate and the Release Note should prioritize being readable.
Note: An excellent walkthrough of the GitHub portion of the releases process is available as a recording in zoom
The first step to a release regardless of whether is the SDK or Meltano is to trigger a version bump. To do so, you’ll manually trigger the Version Bump GitHub action:
major will be used rarely)
Triggering a version bump will create a PR like !891. You’ll need to review this PR and:
Once the change log is groomed, go ahead and copy the raw (markdown) change log contents and use it to update the description of the Draft release corresponding to your version bump on the GitHub releases page (e.g. https://github.com/meltano/sdk/releases). DO NOT publish the release notes.
Once the changelog is groomed, and you’re happy with its state, merge the PR.
Once you’ve merged the version bump PR and copied the description to the draft release, ping Taylor Murphy in the marketing Slack channel, asking them to review the release notes.
Be sure to merge the release PR Before publishing the release. Publishing the release before the version bump PR has landed will cause the PyPI action to fail.
Publishing the release will trigger the PyPI release.
If the release is published before the version bump PR has landed, you will need to start over (don’t forget to stash your groomed changelog somewhere so that you can paste it back in). In this scenario:
When releasing Meltano, there’s one additional step. You’ll need to build/publish images to the Docker hub.
After publishing the Meltano draft, and after you’ve verified that the packages are live on PyPI, you will need to trigger the Docker publish action: https://github.com/meltano/meltano/actions/workflows/docker_publish.yml
dry-run will skip the upload stage, which can be used to run an image scan prior to releasing the new Docker image.
Coordinating with the
#marketing Slack channel, post a release announcement in the
#announcements Slack channel.