Eclipse Graphical Editing Framework (GEF) 3.5.1 (Galileo SR1)

GEF 3.5 will be upwards compatible with GEF 3.4 to the greatest extent possible. Any exceptions will be noted in the 3.5 release notes so that clients can assess the impact of these changes on their plug-ins and products.

API Contract Compatibility: GEF 3.5 will be upwards contract-compatible with GEF 3.4 unless noted. This means that programs in full compliance with contracts specified in 3.4 APIs will automatically be in full compliance with 3.5 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: GEF 3.5 will be upwards binary-compatible with GEF 3.4 unless noted. This means that plug-ins built for GEF 3.4 will continue to work correctly in 3.5 without change. Plug-ins with hard-coded references in their plug-in manifest file to the 3.4 version of GEF plug-ins will work in 3.5 provided the version match rule is "greaterOrEqual" or "compatible" (the default); references using "perfect" or "equivalent" match rules will be broken. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: GEF 3.5 will be upwards source-compatible with GEF 3.4 to the greatest extent possible. This means that source files written to use 3.4 APIs can often be successfully compiled and run against GEF 3.5 APIs. Since source incompatibilities are easy to deal with, maintaining source compatibility is considered much less important than maintaining contract and binary compatibility. The addition of a single method anywhere could be an incompatible source change. For this reason, source-incompatibilities will not be noted.

Non-compliant usage of API's : All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified as API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Ramp Down Policy

When talking about API Freeze above, we always mean public API only. Provisional, experimental or "internal" API are exempt from API freeze or feature freeze, although we will strive for release quality of these components as well.

Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects.

For M6, we plan to be API complete , so there will not be any more breaking API changes or unsolicited API changes. If needed, making non-breaking API change requires an explicit approval of another committer in the regular peer review, while making a breaking API change requires a committer vote on the mailing list with at least two committers voting +1 and no -1s.

For M7, we plan to be functionally complete . We will accept API changes only if regressions are involved, or serious issues need to be addressed. Process for making API changes is the same as in M6. After M7, the remaining Release Candidates are (only) for fixing bugs, or fixing release required items (such as version numbers, licensing, etc.).

After M7, production of release candidates starts . Additional RCs will be produced every week. After the first RC is produced, the time for general functional improvements is long past. The following describes the types of bugs that would be appropriate:

• A regression
• A high priority bug, one that is blocking or critical, and some cases of major severities.
• Documentation and PII files are exceptions to the normal PMC required review, since there is little chance of that breaking anything, though it is still expected to be complete by M6, and remaining work to be only documentation fixes (that is, no refactoring of plugins, build changes, etc, without PMC review and approval).
• In addition to a bug meeting the above priority/severity conditions, there should be a simple, safe, well understood fix that is well isolated from effecting other components, that doesn't affect API or adopters, that has been well reviewed and well tested.
• As each Release Candidate passes, the criteria for weighing the benefit-to-risk ratio criteria gets higher and higher, and as such requires a larger number of committers and PMC members to review.