This guide aims to provide guidance on how to release new versions of the ecctl binary as well as updating all the necessary parts to make it successful. The release will happen automatically via GitHub actions, but there are a few prerequisites to tick before that can be started.
Before starting any release, make sure to open a release checklist issue using the provided release template.
Releasing a new version of the binary implies that there have been changes in the source code which are meant to be released for wider consumption. Before releasing a new version there's some prerequisites that have to be checked.
If applicable, update the cloud-sdk-go dependency in go.mod. In the past the cloud-sdk-go version was tied to the ecctl version. This is no longer the case as the two are released independently.
Since the version updates are now automated via github actions, this is just a double check
Since the source has changed, we need to update the current committed version to a higher version so that the release is published.
The version is currently defined in the Makefile as an exported environment variable called VERSION in the SEMVER format: MAJOR.MINOR.PATCH
SHELL := /bin/bash
export VERSION ?= v1.0.0Say we want to perform a minor version release (i.e. no breaking changes and only new features and bug fixes are being included); in which case we'll update the MINOR part of the version, this can be done with the make minor target, but it should have been updated automatically via GitHub actions.
SHELL := /bin/bash
export VERSION ?= v1.1.0If a patch version needs to be released, the release will be done from the minor branch. For example, if we want to release v1.5.1, we will check out the 1.5 branch and perform any changes in that branch. The VERSION variable in the Makefile should already be up to date, but in case it's not, it can be bumped with the make patch target.
Steps
- Add a new changelog entry to docs/release-notes/index.md (this powers the release notes docs page) See prior release within file as an example.
- Run
make changelogto create a new file innotes/*.md(supports the release notes within the github repo)
After the release notes have been manually curated, a new pull request can be opened with the changelog and release notes.
After the new changelog and version have been merged to master, the only thing remaining is to run make tag. This is the makefile target which will push the GitHub tag and will trigger the corresponding GitHub action which will release ecctl.
After a release has been performed there are still a few things we need to do.
The release process will open a pull request against the homebrew-tap repository, which needs to be approved and merged, see elastic/homebrew-tap#98 as an example.
Previously this required special action to trigger a full docs rebuild. Currently after PR has been merged documentation should be automatically updated within ~30 minutes.
Once the release is done and the documentation is live, you'll need to get in touch with the marketing team to update the downloads website with the correct links and information.
To do this you'll need to open up an issue similar to this one. In that issue you'll see a link to a google doc, do NOT directly edit this doc, but rather add as suggestions the changes to the links and information. The marketing team is pretty quick to answer, but should they miss this issue for some reason you can ping them in the #marketing channel.
There is an open issue to automate this process, but we've not had the bandwidth to dedicate time to work on this.