Release Freezes
The schedule should contain dates for the following freezes. These freezes help GNOME contributors to coordinate their work, to increase quality.
Do remember, if you miss a freeze, it's not the end of the world, because the next 6-month release phase will usually only be 2 or 3 months away. Just make sure it's in a branch or as patch in bugzilla. See Approving/Rejecting freeze breaks, if you think that you need to break a freeze.
Contents
Feature Freeze
Desktop and platform release module additions are finalised, major feature additions are listed. No new modules or features will be accepted for this release period. "Feature" should be interpreted as "Functionality" or "Ability". Bug fixes of existing features are not affected.
This allows developers to concentrate on refining the new features instead of adding yet more functionality.
API/ABI Freeze
No API or ABI changes should be made in the platform libraries. For instance, no new functions, no changed function signatures or struct fields.
This provides a stable development platform for the rest of the schedule.
There should usually be a "Slushy" API/ABI Freeze before the Hard API/ABI Freeze, to encourage developers to think about API problems while they have a chance to correct them.
API freeze is not required for non-platform libraries, but is recommended.
Change Announcement Period
There may be some time before string or UI freeze designated as a change announcement period where changes can still be made but the relevant lists must be notified. For example, gnome-18n may want to know about string changes, and gnome-doc-list may be interested in both UI and string changes.
Slushy UI Freeze
UI review period heats up. Changes to the user interface may only be made in response to UI review bugs (HIG compliance, consistency, etc). Major UI revisions or changes must be done before this date. You can still make string changes (e.g. changing a sentence in a window) before the String Freeze.
This encourages developers to focus on stability and bug-fixing rather than UI changes. At this point, documentation writers do not have to worry that their work will become outdated.
Hard UI Freeze
No UI changes may be made at all without confirmation from the release team and notification to the documentation team.
This often happens at the same time as the String Freeze.
String Freeze
No string changes may be made without confirmation from the i18n team and notification to release team, translation team, and documentation team.
From this point, developers can concentrate on stability and bug-fixing. Translators can work without worrying that the original English strings will change, and documentation writers can take accurate screenshots.
For the string freezes explained, and to see which kind of changes are not covered by freeze rules, check TranslationProject/HandlingStringFreezes.
Hard Code Freeze
This is a late freeze to avoids sudden last-minute accidents which could risk the stability that should have been reached at this point. No source code changes are allowed without approval from the release team, but translation and documentation should continue. Simple build fixes are, of course, allowed without asking.
