📢 Kairos release v3.1.0

[mudler]

🗺 What's left for release

• [x] #2117
• [x] https://github.com/kairos-io/kairos/issues/2200
• [x] https://github.com/kairos-io/kairos/issues/2565
• [x] https://github.com/kairos-io/kairos/issues/2429
• [x] https://github.com/kairos-io/kairos/issues/2138
• [x] https://github.com/kairos-io/kairos/issues/2217
• [x] https://github.com/kairos-io/kairos/issues/2430
• [x] https://github.com/kairos-io/kairos/issues/2048
• [x] https://github.com/kairos-io/kairos/issues/2547
• [x] https://github.com/kairos-io/kairos/issues/2586
• [x] https://github.com/kairos-io/kairos/issues/2608

:bug:

• [x] https://github.com/kairos-io/kairos/issues/2526
• [x] https://github.com/kairos-io/kairos/issues/2212

Next release: https://github.com/kairos-io/kairos/issues/2052

🔦 Highlights

• This is the last release with Ubuntu 23.10 (marked for deprecation)

✅ Release Checklist

• [ ] Stage 0 - Finishing Touches
  • [ ] Check if Kairos-docs were updated and consider tagging them with the same version as Kairos
  • [ ] Check if osbuilder is in the wanted version/latest
  • [ ] Check if any kairos/packages was bumped and they were merged and repo updated (https://github.com/kairos-io/packages)
  • [ ] Check latest repository update was merged, otherwise trigger its job (https://github.com/kairos-io/kairos/actions/workflows/bump_repos.yml)
  • [ ] Make sure CI tests are passing.
  • [x] 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
    • [ ] 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.
  • [ ] 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)
• [ ] Stage 4 - Announcement
  • [ ] Blog post announcement

[mudler]

We have to discuss internally if master does not have many breaking changes yet and has been tested enough by the prod team (cc @vipsharm ) - in that case we will move out some of the items of 3.1.0 to 3.2.0, and leave 3.1.0 to be mostly bug-fixing with small feats in (Ubuntu 24) and get rid of tech debt around 3.0.

jfyi @antongisli

[antongisli]

100%. Let's keep 3.1 as stable as possible and minimize breaking changes.

[jimmykarily]

rc1 one on its way: https://github.com/kairos-io/kairos/releases/tag/v3.1.0-rc1

[jimmykarily]

This should be addressed before we cut the "stable" one: https://www.qualys.com/regresshion-cve-2024-6387/ Let's check when the distros have a patch.

[mudler]

This should be addressed before we cut the "stable" one: https://www.qualys.com/regresshion-cve-2024-6387/ Let's check when the distros have a patch.

not a shipstopper - we can do patch releases.