blob: 42ccd3effc71ae5eda14450f8f5bf085623f4c28 [file] [log] [blame]
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<?xml-stylesheet type="text/xsl" href=""?>
<plan xmlns="" xmlns:html="">
<release projectid="tools.gef" version="3.5.0" />
<html:p>This document lays out the feature and API set for the
feature release of the Graphical Editing Framework (GEF)
designated release 3.5.0.</html:p>
The release deliverables are:
GEF source code for the release is available in the
<html:li>GEF runtime binaries and SDK distributions
<html:li>GEF runtime binaries and SDK features on
(install via Eclipse update manager).</html:li>
GEF builds are available weekly as Integration builds. GEF
Releases are approximately one week after the
Eclipse Milestone
Releases. It is anticipated that GEF will synchronize its
milestones with the
<a href="">
Galileo release schedule
<milestone date="08/20/2008" milestone="M1"></milestone>
<milestone date="09/24/2008" milestone="M2"></milestone>
<milestone date="11/05/2008" milestone="M3"></milestone>
<milestone date="12/17/2008" milestone="M4"></milestone>
<milestone date="02/03/2009" milestone="M5"></milestone>
<milestone date="03/16/2009" milestone="M6">
<html:p>API freeze</html:p>
<milestone date="05/04/2009" milestone="M7"></milestone>
<milestone date="05/18/2009" milestone="RC1"></milestone>
<milestone date="05/25/2009" milestone="RC2"></milestone>
<milestone date="06/01/2009" milestone="RC3"></milestone>
<milestone date="06/08/2009" milestone="RC4"></milestone>
<milestone date="06/15/2009" milestone="RC5"></milestone>
<milestone date="06/26/2009" milestone="2.2.0"></milestone>
GEF 3.5 will support all operating environments supported by the
Platform itself. For a list of supported environments, refer
Eclipse Project 3.5 plan</html:a>
for a list of reference platforms.
<html:p>GEF 3.5 will be upwards compatible with GEF 3.4 to the
possible. Any exceptions will be noted in the 3.5
release notes so that
can assess the impact of these changes on
their plug-ins and products.</html:p>
<html:b>API Contract Compatibility:</html:b>
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
<html:a href=""> Evolving
Java-based APIs</html:a>
for a discussion of the kinds of API changes that maintain
<html:b>Binary (plug-in) Compatibility:</html:b>
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
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
<html:a href=""> Evolving
Java-based APIs</html:a>
for a discussion of the kinds of API changes that maintain
<html:b>Source Compatibility:</html:b>
GEF 3.5 will be upwards source-compatible
with GEF 3.4 to the greatest
extent possible. This means that source
written to use 3.4 APIs
can often be successfully compiled and run against
3.5 APIs. Since
source incompatibilities are easy to deal with,
compatibility is considered much less important than maintaining
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.
<html:b>Non-compliant usage of API's</html:b>
: All non-API methods and classes, and
certainly everything in a
package with "internal" in its name, are considered
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
an earlier releases. Refer to
How to Use the Eclipse API</html:a>
for information about how to write compliant
<html:b>Ramp Down Policy</html:b>
<html:p>When talking about API Freeze above, we always mean public API
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.</html:p>
<html:p>Typically the last week of a Milestone is for testing, and
fixing only regressions and P1 or blocking defects.</html:p>
<html:b>For M6, we plan to be API complete</html:b>
, so there will not be any more breaking API changes or unsolicited
API changes.
If needed, making non-breaking API change requires an
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
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
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
The following describes the types of bugs
that would be appropriate:
<html:li>A regression</html:li>
<html:li>A high priority bug, one that is blocking or critical, and
some cases of major severities.</html:li>
<html:li>Documentation and PII files are exceptions to the normal
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
<html:li>In addition to a bug meeting the above priority/severity
conditions, there should be a simple, safe, well understood fix
is well isolated from effecting other components, that doesn't
affect API or adopters, that has been well reviewed and well
<html:li>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
The project has identified major areas of work, that
will be the
priorities for this development cycle. These areas will
major themes identified by the Eclipse Requirements Council (
2007 Themes and Priorities</html:a>
<theme name="Consumability">
<html:p>This work will make it easier to make effective use of
GEF components. We seek to deliver small enhancements and
fixes that are important for our consumers.
We seek to
issues that block the effective use of the GEF framework.
A list of
those plan items related to Consumability can be found by searching
Bugzilla for flag=galileo.