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 branch or as patch in bugzilla. 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.

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.

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. Bug fixes of existing features are not affected.

To break Feature Freeze you need two approvals from the release-team plus you should also notify your plans to gnome-doc-list@.

UI Freeze

No UI changes may be made at all without two approvals from the release-team and notification to gnome-doc-list@.

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 both gnome-i18n@ and gnome-doc-list@.

String Freeze

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

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 2012-08-28 13:24:42 by ChristopheFergeau)