plan/gef_plan_3_3.php - www.eclipse.org/gef - Git at Google

 <?php  																														require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); 	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); 	$App 	= new App();	$Nav	= new Nav();	$Menu 	= new Menu();		include($App->getProjectCommon());    # All on the same line to unclutter the user's desktop'

 $pageTitle 		= "Eclipse Graphical Editing Framework (GEF)";
 $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">

 <table>
 <tr>
 <td valign="top"><b><font face="Arial,Helvetica"
 style="font-size: 20pt;">GEF Project Plan for Release 3.3 (FINAL)</font></td>
 <td>&nbsp;</td>
 <td align="top"><img src="../images/gefbanner.jpg" border="0"></td>
 </tr>
 </table>
 <p>Last revised <tt>$Date: 2007/05/23 14:04:45 $</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://news.eclipse.org/eclipse.tools.gef">eclipse.tools.gef</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
 3.3.0.</p>

 <ul type="disc">
 <li><a href="#Deliverables">Release deliverables</a></li>

 <li><a href="#Milestones">Release milestones</a></li>

 <li><a href="#TargetOperatingEnvironments">Target operating
 environments</a></li>

 <li><a href="#Compatibility">Compatibility with previous releases</a></li>

 <li><a href="#Themes">Themes / Plan Items</a></li>

 </ul>

 <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="http://bugs.eclipse.org/bugs">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 eclipse.org <a
 href="http://dev.eclipse.org/viewcvs/index.cgi/?cvsroot=Tools_Project">CVS
 repositories for GEF</a>.</li>

 <li>GEF runtime binaries and SDK distributions (downloadable).</li>

 <li>GEF runtime binaries and SDK features on eclipse.org update site
 (install via Eclipse update manager).</li>
 </ul>

 <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
 href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#Milestones">
 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="http://www.eclipse.org/projects/europa.php">Europa Simultaneous
 Release</a>. The
 <a href="http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release">Europa Wiki</a>
 provides the complete summary of the release.</p>

 <p>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.</p>

 <h2><a name="RampDown"> </a>Ramp Down Policy</h2>

 <p>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>
 <ul><li>A regression
 <li>A P1 or P2 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 plug-ins, 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.
 </ul>

 <h2><a name="TargetOperatingEnvironments"> </a> Target Operating
 Environments</h2>

 <p>GEF 3.3 will support all operating environments supported by the Eclipse
 Platform itself. For a list of supported environments, refer to <a
 href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#TargetOperatingEnvironments">
 Eclipse Project 3.3 plan</a> for a list of reference platforms.</p>

 <h2><a name="Compatibility"> </a> Compatibility with Previous Releases</h2>

 <h3>Compatibility of Release 3.3.0 with 3.2.0</h3>

 <p>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.</p>
 <p><b>API Contract Compatibility:</b> 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 <i> <a
 href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs"> 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.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 <i> <a
 href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs"> 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.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.&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
 href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">
 How to Use the Eclipse API</a></i> for information about how to write compliant
 plug-ins.</p>

 <h2><a name="Themes"> </a> Themes</h2>
 <p><img width="12" height="12" src="../images/green-box.gif" border="0" />
 The changes under consideration for the next release of Eclipse GEF address a
 few major themes:</p>

 <ul>
 <li><b>Revisit Performance</b> - GEF has always been a framework for
 delivering integrated tools. With a growing base of both free and commercial
 offerings based on GEF, it's critical for continued success to ensure that the
 framework scales well. This theme is to measure and improve the performance and
 scalability of GEF.</li>

 <li><b>Usability Enhancements</b> - There are various issues raised on the
 usability of GEF based diagrams. This theme is to improve usability of
 applications based on GEF.</li>

 <li><b>Defect Cleanup</b> - There are around 200 open Bugzillas, this theme
 works torward reducing this backlog.</li>

 <li><b>GEF diagram layer test automation</b> - TPTP includes a SWT test
 automation framework which currently does not include diagram (GEF) support.
 This theme is to look at providing integration with GEF for diagram layer
 testing. There is an <a
 href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=133099">enhancement
 request (Bug 133099)</a> for this and it has been frequently requested by the
 community.</li>

 </ul>

 <p>The current status of each plan item is noted:</p>

 <ul type="disc">
 <li><b>Plan Item</b> items - a <i>Plan Item</i> that we have decided to
 address for the release. To see all committed items - see <i>"committed"</i>
 items</li>
 <li><b>Committed</b> items - A committed bug is one that we have decided to
 address for the release.</li>

 <li><b>Proposed</b> items - A bug item is one that we are considering
 addressing for the release. Although we are actively investigating it, we are
 not yet in a position to commit to it, or to say that we won't be able to
 address it. After due consideration, a proposal will either be committed or
 deferred.</li>

 <li><b>Deferred</b> items - A reasonable proposal that will not make it in
 to this release for some reason is marked as deferred with a brief note as to
 why it was deferred. Deferred plan items may resurface as committed plan items
 at a later point.</li>
 </ul>

 </div>

 EOHTML;


 	# Generate the web page
 	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
 ?>
	<?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop'

	$pageTitle = "Eclipse Graphical Editing Framework (GEF)";
	$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">

	<table>
	<tr>
	<td valign="top"><b><font face="Arial,Helvetica"
	style="font-size: 20pt;">GEF Project Plan for Release 3.3 (FINAL)</font></td>
	<td> </td>
	<td align="top"><img src="../images/gefbanner.jpg" border="0"></td>
	</tr>
	</table>
	<p>Last revised <tt>$Date: 2007/05/23 14:04:45 $</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>    Please send comments about this draft plan to
	the</em> <a href="news://news.eclipse.org/eclipse.tools.gef">eclipse.tools.gef</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
	3.3.0.</p>

	<ul type="disc">
	<li><a href="#Deliverables">Release deliverables</a></li>

	<li><a href="#Milestones">Release milestones</a></li>

	<li><a href="#TargetOperatingEnvironments">Target operating
	environments</a></li>

	<li><a href="#Compatibility">Compatibility with previous releases</a></li>

	<li><a href="#Themes">Themes / Plan Items</a></li>

	</ul>

	<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. </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="http://bugs.eclipse.org/bugs">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 eclipse.org <a
	href="http://dev.eclipse.org/viewcvs/index.cgi/?cvsroot=Tools_Project">CVS
	repositories for GEF</a>.</li>

	<li>GEF runtime binaries and SDK distributions (downloadable).</li>

	<li>GEF runtime binaries and SDK features on eclipse.org update site
	(install via Eclipse update manager).</li>
	</ul>

	<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
	href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#Milestones">
	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="http://www.eclipse.org/projects/europa.php">Europa Simultaneous
	Release</a>. The
	<a href="http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release">Europa Wiki</a>
	provides the complete summary of the release.</p>

	<p>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.</p>

	<h2><a name="RampDown"> </a>Ramp Down Policy</h2>

	<p>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>
	<ul><li>A regression
	<li>A P1 or P2 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 plug-ins, 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.
	</ul>

	<h2><a name="TargetOperatingEnvironments"> </a> Target Operating
	Environments</h2>

	<p>GEF 3.3 will support all operating environments supported by the Eclipse
	Platform itself. For a list of supported environments, refer to <a
	href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#TargetOperatingEnvironments">
	Eclipse Project 3.3 plan</a> for a list of reference platforms.</p>

	<h2><a name="Compatibility"> </a> Compatibility with Previous Releases</h2>

	<h3>Compatibility of Release 3.3.0 with 3.2.0</h3>

	<p>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.</p>
	<p><b>API Contract Compatibility:</b> 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 <i> <a
	href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs"> 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.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 <i> <a
	href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs"> 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.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.</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
	href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">
	How to Use the Eclipse API</a></i> for information about how to write compliant
	plug-ins.</p>

	<h2><a name="Themes"> </a> Themes</h2>
	<p><img width="12" height="12" src="../images/green-box.gif" border="0" />
	The changes under consideration for the next release of Eclipse GEF address a
	few major themes:</p>

	<ul>
	<li><b>Revisit Performance</b> - GEF has always been a framework for
	delivering integrated tools. With a growing base of both free and commercial
	offerings based on GEF, it's critical for continued success to ensure that the
	framework scales well. This theme is to measure and improve the performance and
	scalability of GEF.</li>

	<li><b>Usability Enhancements</b> - There are various issues raised on the
	usability of GEF based diagrams. This theme is to improve usability of
	applications based on GEF.</li>

	<li><b>Defect Cleanup</b> - There are around 200 open Bugzillas, this theme
	works torward reducing this backlog.</li>

	<li><b>GEF diagram layer test automation</b> - TPTP includes a SWT test
	automation framework which currently does not include diagram (GEF) support.
	This theme is to look at providing integration with GEF for diagram layer
	testing. There is an <a
	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=133099">enhancement
	request (Bug 133099)</a> for this and it has been frequently requested by the
	community.</li>

	</ul>

	<p>The current status of each plan item is noted:</p>

	<ul type="disc">
	<li><b>Plan Item</b> items - a <i>Plan Item</i> that we have decided to
	address for the release. To see all committed items - see <i>"committed"</i>
	items</li>
	<li><b>Committed</b> items - A committed bug is one that we have decided to
	address for the release.</li>

	<li><b>Proposed</b> items - A bug item is one that we are considering
	addressing for the release. Although we are actively investigating it, we are
	not yet in a position to commit to it, or to say that we won't be able to
	address it. After due consideration, a proposal will either be committed or
	deferred.</li>

	<li><b>Deferred</b> items - A reasonable proposal that will not make it in
	to this release for some reason is marked as deferred with a brief note as to
	why it was deferred. Deferred plan items may resurface as committed plan items
	at a later point.</li>
	</ul>

	</div>

	EOHTML;


	# Generate the web page
	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
	?>