|GEF Project Plan for Release 3.3 (FINAL)|
Last revised : 2007/05/23 14:04:45 $ ( marks interesting changes over a previous revision of this document)
Please send comments about this draft plan to the eclipse.tools.gef newsgroup.
This document lays out the feature and API set for the next feature release of the Graphical Editing Framework (GEF) project, designated release 3.3.0.
Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, plans are posted in an embryonic form and then revised from time to time throughout the release cycle.
The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, and release-to-release compatibility. These are all things that need to be clear for any release, even if no features were to change.
The remainder of the plan consists of plan items for the GEF project. Each plan item covers a feature that is to be added, or some aspect that is to be improved. Each plan item will have its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.
Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single subsystem; others may involve coordinated changes across several projects within the same top-level project; and others may involve coordination with other top-level projects. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.
With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.
The release deliverables are:
GEF builds are available weekly as Integration builds. GEF Milestone Releases are approximately one week after the Eclipse Milestone Releases .
Following the final milestone, release candidates will begin. GEF Release Candidates are planned to be released approximately one week after each Eclipse Release Candidate. This convergence is required to meet the goals of the Europa Simultaneous Release. The Europa Wiki provides the complete summary of the release.
Scheduled release candidates should end in 2007Q2, and beyond that point, will be produced only as needed, leading up to a release in late 2007Q2.
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:
GEF 3.3 will support all operating environments supported by the Eclipse Platform itself. For a list of supported environments, refer to Eclipse Project 3.3 plan for a list of reference platforms.
GEF 3.3 will be upwards compatible with GEF 3.2 to the greatest extent possible. Any exceptions will be noted in the 3.3 release notes so that clients can assess the impact of these changes on their plug-ins and products.
API Contract Compatibility: GEF 3.3 will be upwards contract-compatible with GEF 3.2 unless noted. This means that programs in full compliance with contracts specified in 3.2 APIs will automatically be in full compliance with 3.3 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.3 will be upwards binary-compatible with GEF 3.2 unless noted. This means that plug-ins built for GEF 3.3 will continue to work correctly in 3.3 without change. Plug-ins with hard-coded references in their plug-in manifest file to the 3.2 version of GEF plug-ins will work in 3.3 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.3 will be upwards source-compatible with GEF 3.2 to the greatest extent possible. This means that source files written to use 3.2 APIs can often be successfully compiled and run against GEF 3.3 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.
The changes under consideration for the next release of Eclipse GEF address a few major themes:
The current status of each plan item is noted:
Back to the top