We try to follow the practice of releasing often. That allows us to have smaller releases and thus, hopefully, we'll also break less things while doing so.
Creating a release happens via Github Actions by creating an annotated git tag. Tag creation triggers the release workflow which will do most of the heavy-lifting:
- Create the actual release in releases
- Build
k0sbinary on both AMD64 and ARM64 architectures - Push the bins into the release as downloadable assets
After the action completes, the release will be in draft state to allow manual modification of the release notes. Currently there is no automation for the release notes, this has to be manually collected.
Once the release notes are done we can publish the release.
We're following semantic versioning for version numbering. Currently we're working on 0.y.z series so the rules are interpreted in bit more relaxed way.
We usually bake couple beta or RC releases before pushing out the final release. This allows us to run final verifications on the system with a package that's build exactly the same as a real release.
One of the steps involved in final testing stages for a release is to run Kubernetes conformance tests for a RC build. For more info how to run conformance testing for k0s read this.