Module Requirements

Requirements for GNOME modules and maintainers.

Common Requirements to all Release Sets

  • Maintainers should be familiar with MaintainersCorner.

  • Maintainers should subscribe to devel-announce-list for important changes and reminders.

  • 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.
    • Check your notifications when you branch, and send manual branch notification emails if necessary (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 $MODULE.doap file in your source code repository up-to-date (if your module does not have a $MODULE.doap file, create one).
    We do not need a MAINTAINERS file anymore; though autotool might complain

  • 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
  • Platform Binding requirements

Proposed Additional Requirements

  • User Documentation; brief synopsis: user-oriented modules must notify GDP of any user visible changes by feature freeze

Further resources

ReleasePlanning/ModuleRequirements (last edited 2015-04-02 13:44:25 by AllanDay)