Platform Bindings requirements

Modules in this release set should follow these rules.

Follow the schedule

Platform Bindings project maintainers must follow the freeze and release dates on the schedule, according to the rules here. Here is the current release schedule.

API/ABI freeze

The API must be frozen on the scheduled freeze date. See the Developer Platform API rules, in which any mention of API or ABI can be interrepreted as ABI if the programming language makes no distinction between ABI and API.

Where the programming language has both an API and ABI, it is assumed that the ABI is frozen whenever the API is frozen, and that breaking API is likely to break ABI.

Unlike the Developer Platform, modules in the Platform Bindings may create new parallel-installable APIs more often. This means that you may break API/ABI in the next schedule only if you create a new version of the API which is parallel-installable with the older version. Again, the rule is "Don't break already-installed applications". For instance, GTK+ 2.0 was parallel-installable with GTK+ 1.2. Although bindings might choose to only break API at the same times as the underlying GNOME Platform libraries, bindings are allowed to break API more often, if they follow these rules. Obviously this should be avoided because it does make it more difficult for applications to take advantage of new features, and because we prefer to have fewer API versions from which to choose.

These rules do not specify behaviour for any runtime/interpretation environment used by the binding, though runtime environments will obviously need to do similar things to solve the same problems for application developers. When multiple versions of the runtime may be installed in parallel, associated versions of the Platform Binding should be installed in parallel whever possible.

Version numbers

Platform Bindings project maintainers should follow the normal Developer Platform version numbering scheme.

Try to use the same major.minor numbers that GNOME uses. For instance, GTK+ 2.4.x would be wrapped by gtkmm 2.4.x, and libgnomeui 2.6.x would be wrapped by libgnomeuimm 2.6.x.

You do not need to release a new version just because there is a new release of the underlying GNOME Platform library.

What should be wrapped?

You should try to wrap the entire GNOME Developer Platform, but we do not expect everybody to wrap everything. If you don't want to freeze some of your GNOME Platform bindings then you should say that as early as possible, and package them separately from your official GNOME Binding modules.

You do not need to put everything in one package. Full modularity is good, but not demanded.

This does not include non-developer platform API (such as libgnomeprint, or libgda, at the moment). It's great if you wrap those, but it needs to be done separately.

In summary:

  • Non-GNOME Platform bindings do not belong in GNOME Platform Bindings modules.
  • Bindings that do not follow all of the GNOME Platform Bindings rules do not belong in GNOME Platform Bindings modules.

What projects are official GNOME Platform Bindings?

We only want bindings which can stick to the schedule. Previous history should be the best indicator of a project's ability to do that.

If a binding project misses any freeze date or final release date by more than 2 weeks, it will be removed from the modules list. It will be difficult, but not impossible, to persuade the release-team that you should be on the next release schedule. Of course, anybody is free to follow the schedule even if they are not officially on it. That binding would then have a very good chance of being on the schedule next time.

We will not have more than one binding for the same programming language in the modules list. If a project believes that it has created a better binding for a programming language then it should try to unofficially follow the release schedule for one phase, and then persuade the release-team that the other binding should be removed from the list in favour of the new one. Note that this will be easier if the original binding has been removed anyway because it has missed a schedule date.

Beta Bindings

Bindings that are listed as "Beta" will not make the same guarantees about API/ABI stability. However, they will at least try to achieve API/ABI stability, and they will provide releases on the scheduled dates and follow the other rules. Beta Bindings are expected to be official bindings on the next schedule.

ReleasePlanning/ModuleRequirements/PlatformBindings (last edited 2012-11-07 11:23:07 by MurrayCumming)