We had some confusion and I agree the documentation is a little bit spread on the wiki, so, here is a temptative of a quick summary of what can enter a cycle at a given time.
Note that the release schedule is available once we have the codename of a given release, for instance: https://wiki.ubuntu.com/CosmicCuttlefish/ReleaseSchedule
-
Feature Freeze:
This mostly doesn’t impact Yaru. The goal is to not make any new big and risky feature in. I would say as long as you don’t make a 1000 CSS line diff, don’t bother. -
UI Freeze:
No more major UI change at this point. The goal is for documentation contributors to be able to take screenshots and have consistency between what the final user sees and what’s screenshoted in the documentation. If we want to break this, we can open an UIF exception bug.
This is a bug with:
- Have "UIFe: " in the bug title
- State the reason why you feel those visual changes are necessary (note: you can include multiple in one shot if we want to have one release with multiple changes).
- Subscribe the “ubuntu-release” team to the bug
- Attach the daily build or link to a recent build (the snap logs should be fine)
- Notify the documentation team (not the translation team as we shouldn’t chagne strings). (ubuntu-doc@). State that you notified that team on the bug report as well.
Only once we get the ack from the documentation team on the bug, we can merge to master the change.
Note that small UI changes like border colors, basically things that are minor and won’t jump on your eyes/introduce confusion when reading the documentation compared to the final (updated) version are ok. Those are “bug fixes”.
-
Final Freeze:
The goal is to have a working finale iso image. We don’t release any chagnes that are not release critical at this time. Please refrain to merge to master 2 days before the Final Freeze, as we want to cut a release the day before Final Freeze.
-> Then, the release happens, and we can branch “master” and a maintenance branch like “cosmic” (remember the snap will always use master).
-
Stable Release Update:
This is once a version is released and we want to backport some fixes in master to the maintenance branch. The idea is to only backport bug fixes (no UI changes of course) to stable release.
The process is to open one or more bugs with a clear state of the changes. There is a template to copy.
Then, subscribe ubuntu-sru to it. You can merge to the maintenance branch.
Once uploaded and accepted by the SRU team, the package will only migrated to -proposed to (and so, will be generally available) if:
- all bugs are confirmed as being fixed (here to see how to do so)
- a period of 7 days of retention have passed without any regression triggered/found.
-> Work can continue merging to the maintenance branch or master meanwhile.