Release Freezes

The GNOME schedule contains 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 merge request on GitLab. See Approving/Rejecting freeze breaks, if you think that you need to break a freeze.

End of Feature Proposals period

Desktop and platform release module additions are finalised, major system wide feature additions are listed. No new modules or features will be accepted for this release period. "Feature" should be interpreted as "Functionality" or "Ability" that affects more than one module.

This allows developers to concentrate on refining the new features instead of adding yet more functionality.

The Freeze

The Freeze consists of three freezes and the string change announcement period that were previously independent:

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. API freeze is not required for non-platform libraries, but is recommended.

To break API/ABI Freeze you need two approvals from the release team.

Feature Freeze

No new features can be added anymore so developers focus on stability and the GNOME Documentation Project can document the existing functionality. Bugfixes of existing features are still allowed.

To break Feature Freeze you need two approvals from the release team.

UI Freeze

No major UI changes may be made at all without two approvals from the release team. Small fixes do not require permission.

String Change Announcement Period

The time before string freeze designated as a change announcement period where string changes can still be made (e.g. for typo fixes or translatability improvements). All string changes must be announced to gnome-i18n@.

String Freeze

No string changes may be made without two approvals from the Translation Coordination Team (via sending an email to gnome-i18n@).

From this point, developers should 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 two approvals from the release team, but translation and documentation should continue. Simple build fixes are, of course, allowed without asking.

Approving/Rejecting Freeze Breaks

See ReleasePlanning/RequestingFreezeBreaks

ReleasePlanning/Freezes (last edited 2020-08-18 14:28:48 by MichaelCatanzaro)