Skip to content

Latest commit

 

History

History
77 lines (46 loc) · 5.67 KB

RELEASE-PROCESS.md

File metadata and controls

77 lines (46 loc) · 5.67 KB
Raw

Release Process

The process of releasing a new version of the KEDA HTTP Add-on involves a few steps, detailed below.

The process herein is largely automated but we recognize that there may be more that we can automate. If you find something that can and should be automated, and you believe that you know how, please submit an issue explaining how.

1: Current and new versions

Please go to the releases page and observe what the most recent release is. Specifically, note what the tag of the release is. For example, if version 0.3.0 is the latest release (it is as the time of this writing), the tag for that is v0.3.0.

To determine the new version, follow SemVer guidelines. Most releases will increment the PATCH or MINOR version number.

2. Changelog

Add a new section in CHANGELOG.md for the new version that is being released along with the new features, patches and deprecations it introduces.

It should not include every single change but solely what matters to our customers, for example issue template that has changed is not important.

3. Add the new version to GitHub Bug report template

Add the new released version to the list in KEDA Version dropdown in 2_bug_report.yml.

4: Create a new GitHub release

Create a new release on the GitHub releases page, using your new release number.

The title of the release should be "Version 1.2.3", substituting 1.2.3 with the new version number, and the Git tag should be v1.2.3, again substituting 1.2.3 with your new version number.

The release description should be a short to medium length summary of what has changed since the last release. The following link will give you a list of commits made since the v0.3.0 tag: github.com/kedacore/http-add-on/compare/v0.3.0...main. Replace v0.3.0 for your appropriate most recent last tag to get the commit list and base your release summary on that list.

After you create the new release, automation in a GitHub action will build and deploy new container images.

5: Submit a PR to the Helm Charts Repository

The scope of the changes you'll need to make to the Helm chart vary, but the below list is the minimum set of fields to change:

  • The appVersion field in Chart.yaml. If you've chosen 1.2.3 as the version number, this field should read:
appVersion: 1.2.3
  • The images.tag field in values.yaml. If you've chosen 1.2.3 as the version number, this field should read:
images:
  # tag is the image tag to use for all images.
  # for example, if the operator image is "myoperator" and
  # tag is "mytag", the operator image used will be
  # "myoperator:mytag". `latest` is used to indicate the latest
  # stable release in the official images, `canary` is
  # the build for the latest commit to the `main` branch,
  # and you can target any other commit with `sha-<GIT_SHA[0:7]>`
  tag: 1.2.3

Note: The container images generated by CI/CD in step 2 will have the same tag as the tag you created in the release, minus the v prefix. You can always see what images created by going to the container registry page for the interceptor, operator or scaler

Once you've made changes to the chart, here's how to do submit the change to the charts repository:

  • Submit a Pull Request (PR) to the github.com/kedacore/charts repository with your changes. Also ensure that you follow the Shipping a new version guidelines in the charts documentation to complete the chart release.
  • Your chart changes must go into the http-add-on directory. The release artifact will go into the docs directory.
  • Ensure that you add a link to the HTTP Add-on repository and the new release number, so that PR reviewers are aware what the work relates to
  • Work with the maintainers of that repository to get the chart merged

After your PR is merged, you've completed the release. Congratulations! You can optionally write a blog post about it; see the next section if you're interested.

6: Publish release on Artifact Hub

Publish release on Artifact Hub by creating a new version in kedacore/external-scalers.

7: Write a blog post on the documentation site (optional)

If you believe that your release is large enough to warrant a blog post on the keda.sh/blog site, please go to github.com/kedacore/keda-docs and submit a new PR with a blog article about the release.

Include in the article a longer summary of changes and any important information about the new functionality, bugfixes, or anything else appropriate. The post should go into the content/blog directory.