API Compatibility in Mozilla 2+

[Benjamin Smedberg]

This is a followup to presentations which occurred in the development
meeting in June, as well as presentations at the Mozilla summit. Please
direct questions and followup to the mozilla.dev.platform group.

In order to improve performance and maintain the Mozilla codebase, we have
decided that now is the right time to make more aggresive changes which
break older code in ways which are not backwards-compatible. This is already
evident in the changes to XPCOM registration, and will be continued in the
future. As part of this decision, we have switched the Gecko version number
to "2.0" for the next major release (Firefox 4).

The new rules for interface compatibility are written here:

https://developer.mozilla.org/En/Developer_Guide/Interface_Compatibility

There are different "layers" of compatibility:

* Web content APIs: very stable
* Jetpack APIs (when the Jetpack SDK reaches version 1.0). Stable.
Compatibility will preserved if at all possible.
* Scriptable APIs (JS/XUL/XBL): May change between major versions.
Developers should carefully consider the impact of changes, however, and
design APIs to be backward- and forward-compatible when appropriate.
* Binary APIs (XPCOM interfaces): extensions with XPCOM binaries will need
to be recompiled with each major version of the platform (2.0, 2.1, etc).
Interfaces formerly marked with @status FROZEN are no longer considered
frozen and may change in the future.

We have been preparing for this change for a while: the ctypes and jetpack
projects are designed so that developers can transition from unstable XPCOM
interfaces to stable APIs.

Note that the change to "Mozilla 2" does not mean that we are switching to
GCed XPCOM objects, nor are we switching to C++ exceptions. This is not
"opening the floodgates" to make lots of arbitrary changes to APIs just
because they are now unfrozen. All changes should be carefully considered,
weighing the potential benefits against the costs both within the Mozilla
codebase and to third-party code such as extensions.

We are not planning on re-freezing XPCOM interfaces in the future.

--BDS