You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider cutting an rc, alpha, ... based on changes on the CI
Stage 1 - Manual testing
How: Using the assets from master, make sure that test scenarios not covered by automatic tests are passing, and that docs are still aligned
Fedora flavor install, and manual upgrade works
Any flavor interactive install
Any flavor recovery reset
Any flavor k3s
ARM images (openSUSE, alpine) boots and manual upgrade works
ARM images passive and recovery booting
ARM images reset works
ARM images /oem exists
Stage 3 - Release
Tag the release on master
Update the release with any known issues
Stage 4 - Announcement
Merge docs updates for kairos and k3s version updates
Create a branch vX.Y.Z on the docs (not tagging), so the new release can be built and displayed on the menu. Ideally open a PR so we can review and add/remove some commits if needed (in case we have documented WIP which is not available on the given release)
Blog post announcement
The text was updated successfully, but these errors were encountered:
Hello @mudler, thank you for opening this issue to clarify the tasks for a Kairos release. Could you please provide more information about what each of these checks does and why they are important? Additionally, are there any specific versions of the relevant artifacts that should be used for this release?
🗺 What's left for release
🔦 Highlights
< top highlights for this release notes >
✅ Release Checklist
rc
,alpha
, ... based on changes on the CIvX.Y.Z
on the docs (not tagging), so the new release can be built and displayed on the menu. Ideally open a PR so we can review and add/remove some commits if needed (in case we have documented WIP which is not available on the given release)The text was updated successfully, but these errors were encountered: