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.
Unless this is a patch release, make sure a cloud-sdk-go release with the same version has been made. Once this is done, the cloud-sdk-go dependency should be updated to that version. To update the cloud-sdk-go dependency, please update the version in go.mod.
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.
Once the version is updated, we can then generate the changelog and release notes by calling make changelog.
Take a look at one of our previous releases v1.5.0.adoc and the template we use to generate them. The idea is to fill all the applicable sections so that users can consume easily.
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.
In order to have the documentation live for our new release we need to modify the conf.yaml file in the docs repository to add the release branch and have the build point to our new branch. (Example PR)
Once the PR for the above changes has been merged, you'll need to run a full doc rebuild to make the new release branch the default docs.
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.