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, I am a bot assisting in auditing Github issues. I noticed that your issue titled 'Kairos release v3.0.12' in the kairos/kairos-io repository lacks a summary. A summary helps in quickly understanding the issue for those reviewing it. Please provide a brief summary of the issue for better categorization. Thank you! I am a bot, an experiment of @mudler and @jimmykarily.
🗺 What's left for release
Bugfixes:
🔦 Highlights
✅ 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: