[x] Update the CHANGELOG.md file with the new version number and release notes.
[x] Run tests and linting, and make sure the version running in the default branch is working end-to-end. At least the minimal end-to-end manual tests is mandatory.
[x] π¨ DO NOT RELEASE before holidays or weekends! Mondays and Tuesdays are preferred.
Merging the Branches
[x] When the team is confident the release is stable, you'll need to create two pull requests:
[x] release/x.y.z -> main: π¨ Do not squash-and-merge! This PR should be merged with a merge commit. #475
[x] release/x.y.z -> develop: this should be merged after the main branch is merged. π¨ Do not squash-and-merge! This PR should be merged with a merge commit. #476
Publishing the Release
[x] After the release branch is merged to main, create a new release on GitHub with the name x.y.z and the use the same changes from the CHANGELOG.md file β v3.0.0
Release Checklist
Git Preparation
x.y.z
.x.y.z
".develop
branch, following the gitflow naming patternrelease/3.0.0
.Code Preparation
version
andappVersion
in helmchart/sdp/Chart.yaml.Version
in main.goMerging the Branches
release/x.y.z -> main
: π¨ Do not squash-and-merge! This PR should be merged with a merge commit. #475release/x.y.z -> develop
: this should be merged after themain
branch is merged. π¨ Do not squash-and-merge! This PR should be merged with a merge commit. #476Publishing the Release
main
, create a new release on GitHub with the namex.y.z
and the use the same changes from the CHANGELOG.md file β v3.0.0