<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<?xml-stylesheet type="text/xsl" href="http://www.eclipse.org/projects/project-plan.xsl"?>
<plan xmlns="http://www.eclipse.org/project/plan" xmlns:html="http://www.w3.org/1999/xhtml">
	<release projectid="tools.gef" version="3.5.0" />
	<introduction>
		<html: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.5.0.</html:p>
	</introduction>
	<release_deliverables>
		<html:p>
			The release deliverables are:
			<html:ul>
				<html:li>
					GEF source code for the release is available in the eclipse.org
					<html:a
						href="http://dev.eclipse.org/viewcvs/index.cgi/?cvsroot=Tools_Project">CVS
						repositories</html:a>
					.
				</html:li>
				<html:li>GEF runtime binaries and SDK distributions
					(downloadable).
				</html:li>
				<html:li>GEF runtime binaries and SDK features on eclipse.org
					update
					site
					(install via Eclipse update manager).</html:li>
			</html:ul>
		</html:p>
	</release_deliverables>
	<release_milestones>
		<preamble>
			<html:p>
				GEF builds are available weekly as Integration builds. GEF
				Milestone
				Releases are approximately one week after the
				Eclipse Milestone
				Releases. It is anticipated that GEF will synchronize its
				release
				milestones with the
				<a href="http://wiki.eclipse.org/index.php/Galileo_Simultaneous_Release">
					Galileo release schedule
					</a>
				.
			</html:p>
		</preamble>
		<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>
		<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>
	</release_milestones>
	<target_environments>
		<html:p>
			GEF 3.5 will support all operating environments supported by the
			Eclipse
			Platform itself. For a list of supported environments, refer
			to
			<html:a
				href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_4.html#TargetOperatingEnvironments">
				Eclipse Project 3.5 plan</html:a>
			for a list of reference platforms.
		</html:p>
	</target_environments>
	<compatibility_with_previous_releases>
		<html:p>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.</html:p>
		<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="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs"> Evolving
				Java-based APIs</html:a>

			for a discussion of the kinds of API changes that maintain
			contract
			compatibility.
		</html:p>
		<html:p>
			<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
			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

			<html:a href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs"> Evolving
				Java-based APIs</html:a>

			for a discussion of the kinds of API changes that maintain
			binary
			compatibility.
		</html:p>
		<html:p>
			<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
			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.
		</html:p>
		<html:p>
			<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
			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
			<html:a
				href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">
				How to Use the Eclipse API</html:a>
			for information about how to write compliant
			plug-ins.
		</html:p>
		<html:p>
			<html:b>Ramp Down Policy</html:b>
		</html:p>
		<html:p>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.</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: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
			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.
		</html:p>
		<html:p>
			<html:b>
				For M7, we plan to be functionally complete
				</html: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.).
		</html:p>
		<html:p>
			<html:b>
				After M7, production of release candidates starts
			</html: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:
		</html:p>
		<html:ul>
			<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
				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).</html:li>
			<html: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.
			</html:li>
			<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
				review.</html:li>
		</html:ul>
	</compatibility_with_previous_releases>
	<themes_and_priorities>
		<preamble>
			<html:p>
				The project has identified major areas of work, that
				will be the
				priorities for this development cycle. These areas will
				address
				the
				major themes identified by the Eclipse Requirements Council (
				<html:a
					href="http://www.eclipse.org/org/councils/roadmap_v3_0/themes_v3_0.php">Eclipse
					2007 Themes and Priorities</html:a>
				).
			</html:p>
		</preamble>
		<theme name="Consumability">
			<description>
				<html:p>This work will make it easier to make effective use of
					the
					GEF components. We seek to deliver small enhancements and
					defect
					fixes that are important for our consumers.
					We seek to
					addresses
					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.
				</html:p>
			</description>
			<committed
				bugzilla="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;classification=Tools&amp;product=GEF&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=substring&amp;keywords_type=allwords&amp;keywords=&amp;emailtype1=substring&amp;email1=&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=flagtypes.name&amp;type0-0-0=substring&amp;value0-0-0=galileo&amp;field0-1-0=flagtypes.name&amp;type0-1-0=notsubstring&amp;value0-1-0=galileo-&amp;field0-2-0=target_milestone&amp;type0-2-0=notequals&amp;value0-2-0=---">
			</committed>
			<proposed
				bugzilla="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;classification=Tools&amp;product=GEF&amp;target_milestone=---&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=substring&amp;keywords_type=allwords&amp;keywords=&amp;emailtype1=substring&amp;email1=&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=flagtypes.name&amp;type0-0-0=substring&amp;value0-0-0=galileo&amp;field0-1-0=flagtypes.name&amp;type0-1-0=notsubstring&amp;value0-1-0=galileo-">
			</proposed>
			<deferred
				bugzilla="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;classification=Tools&amp;product=GEF&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;keywords_type=allwords&amp;keywords=&amp;emailtype1=substring&amp;email1=&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Reuse+same+sort+as+last+time&amp;field0-0-0=flagtypes.name&amp;type0-0-0=equals&amp;value0-0-0=galileo-">
			</deferred>
		</theme>
	</themes_and_priorities>
</plan>