Module Requirements
Modules in the various release sets must follow a few simple rules to ensure quality:
Common Requirements to all Release Sets
Read MaintainersCorner at least once.
Subscribe to devel-announce-list for important changes and reminders (rarely gets more than 12 emails per month).
- Modules must be buildable at all times (this includes the HEAD/TRUNK/etc. development versions); build-breaking changes should be done in special branches.
Follow the release schedule (simplified version) unless the module is specifically listed as an exception (e.g. gtk+)
Try to make a release for each point release on the schedule, within the time specified, if any code or translations or documentation has changed (yes, you will be given slack for occasionally missing releases or making a release early, but not necessarily for releasing late).
Do not break freezes without prior approval.
- Report (hopefully unintentional) freeze breaks to the release-team, with suggestions on how to proceed (revert, request approval belatedly, etc.). Freeze breaks that are less than a few days old and not incorporated into any release need not be reported if they are immediately reverted.
Remember to send out notification emails when branching (to the lists specified at MaintainersCorner).
- Releases must be uploaded to GNOME FTP (releases can also be hosted elsewhere, but not as a replacement to GNOME FTP).
- Please either (a) at least use GNOME's minor version number (e.g. 1.17.6 for a GNOME 2.17.x release) or (b) prominently specify in either your changelog or README which version of GNOME you are targetting with each release of your software.
Follow the branching practices at MaintainersCorner.
Do not add any external dependencies other than those already approved for that cycle (e.g. http://live.gnome.org/TwoPointSeventeen/ExternalDependencies). This includes not depending on a newer version than what is already approved.
- Keep the MAINTAINERS file in your source code repository up-to-date (if your module does not have a MAINTAINERS file, create one).
Strive to excel in the general guidelines used to judge new modules.
Specific Requirements for each Release Set
- Admin
- Same specific requirements as Desktop
- Developer Tools
- Same specific requirements as Desktop
- Desktop
May depend on the platform release set. May also depend on either the gtkmm or python bindings; new modules may depend on gtk#/mono but existing modules without a gtk#/mono dependency must be explicitly approved by the community and release-team as part of the module proposal process. Usage of other bindings not yet permitted.
For widely used libraries which are part of the Desktop release set (e.g. libwnck), please avoid API/ABI changes after feature freeze and discuss any such changes on desktop-devel-list.
- Platform requirements
- May not depend on any other release set
- Platform Binding requirements
- May depend on platform release set only
Proposed Additional Requirements
User Documentation; brief synopsis: user-oriented modules must notify GDP of any user visible changes by feature freeze
