API Compatibility in Mozilla 2+

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