Difference between revisions of "Development Team/Release"
| Line 9: | Line 9: | ||
* Does not duplicate the functionalities of other activities. | * Does not duplicate the functionalities of other activities. | ||
* ... | * ... | ||
| + | |||
| + | == Feature freeze == | ||
| + | |||
| + | The feature freeze affects all the modules included in the release and comprise also strings and ABI for public libraries. Exceptions might be considered by the release team but they will be extremely rare. | ||
| + | |||
| + | == Hard code freeze == | ||
| + | |||
| + | When the hard code freeze is in effect, each and every code change should be approved by the release team. Only critical fixes will be considered. | ||
Revision as of 04:03, 10 May 2008
New features proposal
At the beginning of each release cycle, maintainers will write a proposal for each major new feature they plan to develop. They will be discussed on the Sugar mailing list, revises on the base of the feedback and made available on the wiki. New modules will require explicit approval by the release team.
As part of this new activities will be proposed for inclusion. Criteria for approval will be:
- The maintainer is willing to follow the Sugar schedule.
- Supports internationalisation and localisation.
- Does not duplicate the functionalities of other activities.
- ...
Feature freeze
The feature freeze affects all the modules included in the release and comprise also strings and ABI for public libraries. Exceptions might be considered by the release team but they will be extremely rare.
Hard code freeze
When the hard code freeze is in effect, each and every code change should be approved by the release team. Only critical fixes will be considered.