Difference between revisions of "Development Team/Release"
| Line 1: | Line 1: | ||
== New features proposal == | == New features proposal == | ||
| − | At the beginning of each release cycle, maintainers will write a proposal for each major new feature they plan to develop. | + | At the beginning of each release cycle, maintainers will write a proposal for each major new feature they plan to develop. These 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: | As part of this new activities will be proposed for inclusion. Criteria for approval will be: | ||
| Line 9: | Line 9: | ||
* Does not duplicate the functionalities of other activities. | * Does not duplicate the functionalities of other activities. | ||
* ... | * ... | ||
| + | |||
| + | == Module release == | ||
| + | |||
| + | For both intermediates and final releases module maintainers are responsible to announce module release and make the sources available. More in detail: | ||
| + | |||
| + | * Build a source tarball, test it carefully and make it available in a stable location. | ||
| + | * Send an announce mail to announce@sugarlabs.org. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and an high level, user targeted list of changes. | ||
== Feature freeze == | == Feature freeze == | ||
| Line 17: | Line 24: | ||
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. | 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. | ||
| + | |||
| + | == Automation == | ||
| + | |||
| + | TBD Many of the steps described in this document can be easily automated or maintainers which are using the sugarlabs infrastructure. As a first pass we want to get the workflow right though, even if it involves more manual step than strictly required. | ||
Revision as of 05:12, 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. These 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.
- ...
Module release
For both intermediates and final releases module maintainers are responsible to announce module release and make the sources available. More in detail:
- Build a source tarball, test it carefully and make it available in a stable location.
- Send an announce mail to announce@sugarlabs.org. The form will be decided by each maintainer but it should at least include a reference to the source code tarball and an high level, user targeted list of changes.
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.
Automation
TBD Many of the steps described in this document can be easily automated or maintainers which are using the sugarlabs infrastructure. As a first pass we want to get the workflow right though, even if it involves more manual step than strictly required.