blob: 3e146c02a23907f1e5787ebdfa69347138f1cb39 [file] [log] [blame]
<?php require_once($_SERVER['DOCUMENT_ROOT'] . "/"); require_once($_SERVER['DOCUMENT_ROOT'] . "/"); require_once($_SERVER['DOCUMENT_ROOT'] . "/"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop'
$pageTitle = "GEF Project Plan for Release 3.4 (DRAFT)";
$pageKeywords = "Eclipse Graphical Editing Framework (GEF)";
$pageAuthor = "Anthony Hunter, IBM Rational Software";
# Paste your HTML content between the EOHTML markers!
$html = <<<EOHTML
<div id="midcolumn">
<td valign="top"><b><font face="Arial,Helvetica"
style="font-size: 20pt;">GEF Project Plan for Release 3.4</font></td>
<td align="top"><img src="../images/gefbanner.jpg" border="0"></td>
<p>Last revised <tt>$Date: 2008/05/05 20:27:16 $</tt> ( <img width="12"
height="12" src="../images/green-box.gif" border="0" /> marks interesting
changes over a previous revision of this document)</p>
<p><em>&nbsp;&nbsp;&nbsp; Please send comments about this draft plan to
the</em> <a href="news://"></a> <em>newsgroup.</em></p>
<p>This document lays out the feature and API set for the next feature
release of the Graphical Editing Framework (GEF) project, designated release
<ul type="disc">
<li><a href="#Deliverables">Release deliverables</a></li>
<li><a href="#Milestones">Release milestones</a></li>
<li><a href="#RampDown">Ramp Down Policy</a></li>
<li><a href="#TargetOperatingEnvironments">Target operating
<li><a href="#Compatibility">Compatibility with previous releases</a></li>
<li><a href="#Significant Plan Items">Significant Plan Items</a></li>
<li><a href="#Plan Items Queries">Plan Items Queries</a></li>
<p>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.</p>
<p>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.&nbsp;</p>
<p>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 <a
href="">Eclipse Bugzilla</a> 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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="Deliverables"></a>Release Deliverables</h2>
<p>The release deliverables are:</p>
<ul type="disc">
<li>Source code release for GEF is available in the <a
repositories for GEF</a>.</li>
<li>GEF runtime binaries and SDK distributions (downloadable).</li>
<li>GEF runtime binaries and SDK features on update site
(install via Eclipse update manager).</li>
<h2><a name="Milestones"> </a> Release Milestones</h2>
<p>GEF builds are available weekly as <em>Integration builds</em>. GEF
Milestone Releases are approximately one week after the <a
Eclipse Milestone Releases </a>.</p>
<p>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 <a
href="">Ganymede Simultaneous
Release</a>. The
<a href="">Ganymede Wiki</a>
provides the complete summary of the release.</p>
<p>Scheduled release candidates should end in 2008Q2, and beyond that point,
will be produced only as needed, leading up to a release in late 2008Q2.</p>
<h2><a name="RampDown"> </a><img width="12"
height="12" src="../images/green-box.gif" border="0" />Ramp Down Policy</h2>
<p>For reference, see the
<a href="">Ganymede Simultaneous Release</a>, in
particular the
<a href="">Ganymede Simultaneous Release#Milestones and Release Candidates</a>.</p>
<p>When talking about API Freeze, 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.</p>
<p>Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects.</p>
<p><b>For M6, we plan to be API complete</b>, 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.</p>
<p><b>For M7, we plan to be functionally complete</b>. 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.).</p>
<p><b>After M7, production of release candidates starts</b>. 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:</p>
<li>A regression
<li>A high priority bug, one that is blocking or critical, and some cases of major severities.
<li>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).
<li>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.
<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 review.
<h2><a name="TargetOperatingEnvironments"> </a> Target Operating
<p>GEF 3.4 will support all operating environments supported by the Eclipse
Platform itself. For a list of supported environments, refer to <a
Eclipse Project 3.4 plan</a> for a list of reference platforms.</p>
<h2><a name="Compatibility"> </a> Compatibility with Previous Releases</h2>
<h3>Compatibility of Release 3.4.0 with 3.3.0</h3>
<p>GEF 3.4 will be upwards compatible with GEF 3.3 to the greatest extent
possible. Any exceptions will be noted in the 3.4 release notes so that clients
can assess the impact of these changes on their plug-ins and products.</p>
<p><b>API Contract Compatibility:</b> GEF 3.4 will be upwards
contract-compatible with GEF 3.3 unless noted. This means that programs in full
compliance with contracts specified in 3.3 APIs will automatically be in full
compliance with 3.4 APIs. Refer to <i> <a
href=""> Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that maintain
contract compatibility.</p>
<p><b>Binary (plug-in) Compatibility:</b> GEF 3.4 will be upwards
binary-compatible with GEF 3.3 unless noted. This means that plug-ins built for
GEF 3.4 will continue to work correctly in 3.4 without change. Plug-ins with
hard-coded references in their plug-in manifest file to the 3.3 version of GEF
plug-ins will work in 3.4 provided the version match rule is "greaterOrEqual" or
"compatible" (the default); references using "perfect" or "equivalent" match
rules will be broken. Refer to <i> <a
href=""> Evolving
Java-based APIs</a></i> for a discussion of the kinds of API changes that maintain
binary compatibility.</p>
<p><b>Source Compatibility:</b> GEF 3.4 will be upwards source-compatible
with GEF 3.3 to the greatest extent possible. This means that source files
written to use 3.3 APIs can often be successfully compiled and run against GEF
3.4 APIs. Since source incompatibilities are easy to deal with, maintaining
source compatibility is considered much less important than maintaining contract
and binary compatibility.&nbsp; The addition of a single method anywhere could
be an incompatible source change.&nbsp; For this reason,
source-incompatibilities will not be noted.</p>
<p><b>Non-compliant usage of API's</b>: 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 <i> <a
How to Use the Eclipse API</a></i> for information about how to write compliant
<h2><a name="Significant Plan Items"></a>Significant Plan Items</h2>
<p>The planned changes under consideration for the next release of Eclipse GEF include a
few significant plan items:</p>
<li><b>Modernized GEF Palette</b> - The existing GEF palette UI has been unchanged for quite some time. Meanwhile
the platform has undergone a number of changes. This enhancement has the goal
to get a refreshed palette UI into GEF.
See <a href="">Bugzilla 204631</a></li>
<li><b>Zest Visualization Toolkit</b> - The Zest Visualization Toolkit will become part of GEF,
moving from the Mylyn tools component.
See <a href="">Bugzilla 164387</a></li>
<li><b>Defect Cleanup</b> - There are well over 250 open Bugzillas, this plan item
works toward reducing this backlog. There is an expectation that the GEF community
will assist by contributing patches for bugs they want to see fixed in the 3.4 release.
<a href="">All Open Defects</a></li>
<h2><a name="Plan Items Queries"> </a>Plan Item Queries</h2>
<h2>Plan Items</h2>
<a href="">
3.4 M1</a> |
<a href="">
3.4 M2</a> |
<a href="">
3.4 M3</a> |
<a href="">
3.4 M4</a> |
<a href="">
3.4 M5</a> |
<a href="">
3.4 M6</a> </p>
<h3>Committed Items</h3>
<p>Bugzillas with a target milestone and developer assigned are considered committed items for the release.
<p>For the most current list of these committed items for the 3.4 release, see the following link:</p>
<p><a href="">
All Open Committed Items</a> |
<a href="">
All Resolved Committed Items</a></p>
<h3>Proposed Items</h3>
<p>Bugzillas with a target milestone and no developer assigned are considered proposed items for the release.
For the most current list of these proposed items for the 3.4 release, see the following links:</p>
<p><a href="">
All Open Proposed Items</a>
<h3>Deferred Items</h3>
<p>Bugzillas with an unspecified target milestone are deferred, and not scheduled for the current release.
<h3>Help Wanted Items</h3>
<p>Bugzillas with a 'helpwanted' keyword are in need of contribution from the community.</p>
# Generate the web page
$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);