Project Plan For e4, version July 2010

Table of Contents

• Introduction
• Release Deliverables
• Release Milestones
• Target Environments
• Compatibility with Previous Releases
• Themes and Priorities

Last revised 15:00 ET July 28, 2010.

Please send comments about this plan to the e4-dev@eclipse.org developer mailing list.

This draft document lays out the feature and API set for the next feature release of the Eclipse e4 project, designated the July 2010 release.

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, we (the e4 team) post plans in an embryonic form and revise them 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 all of the component areas under the e4 Project. Each plan item covers a feature or API that is to be added to the e4 Project deliverables, or some aspect of the e4 Project that is to be improved. Each plan item has 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 component; others may involve coordinated changes to several components; other may pervade the entire project. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order.

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 current status of each plan item is noted:

• Committed plan item - A committed plan item is one that we have decided to address for the release.
• Proposed plan item - A proposed plan 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.
• Deferred plan item - 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.

The complete set of release deliverables for the e4 project will include:

• Source code release for all e4 Project deliverables, available as versions tagged "R1_0" in the e4 Project CVS repository.
• e4 master zip (downloadable). Contains all source code, e4 bundles in binary form, and patches for applying portions of e4 onto an existing instance of the Eclipse Platform.
• A p2 repository of binary release deliverables, maintained in a public, stable location on the http://eclipse.org Web site.

Our target is to complete the release in late July 2010, one month after the Helios release. All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations listed below.

In order to remain current, each e4 Project release targets reasonably current operating environments.

Most of the e4 Project is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.0, J2SE 1.3 and 1.4, etc.). In general, the July 2010 release of the e4 Project is developed on Java SE 5.

e4 has dependencies on components from other Eclipse projects, notably the Platform project, and the EMF project. While specific version dependencies may specify a wider range, e4 is generally built and tested against the versions contained in the Helios release train.

There are many different implementations of the Java Platform running atop a variety of operating systems. We focus our testing on a handful of popular combinations of operating system and Java Platform; these are our reference platforms. Eclipse undoubtedly runs fine in many operating environments beyond the reference platforms we test. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Eclipse on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Eclipse on a reference platform.

e4 also has dependencies on browser technologies such as JavaScript. The reference platforms listed below show the versions of these technologies that we are developing and testing against.

e4 July 2010 is tested and validated on the following reference platforms (this list is updated over the course of the release cycle):

As stated above, we expect that e4 works fine on other current Java VM and OS versions but we cannot flag these as reference platforms without significant community support for testing them.

Compatibility of e4 July 2010 with previous Eclipse project releases

e4 July 2010 will not be compatible with previous releases of e4, such as the e4 0.9 release. This includes binary compatibility, contract compatibility, workbench model compatibility, and workspace compatibility.

e4 July 2010 includes a set of bundles that are binary and API contract compatible with Eclipse Platform UI API from the Eclipse Helios (3.6) release. This set of bundles is known as the compatibility layer, and is intended to be used to create a full Eclipse SDK release on e4 that is fully compatible with previous Eclipse project releases. Thus while e4 July 2010 itself is not compatible with previous Eclipse project releases, it provides the necessary infrastructure to allow a fully compatible e4-based release of the Eclipse SDK to be created.

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 in the Eclipse e4 API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

The plan items listed below were defined according to contributor requirements and the themes and priorities established by the e4 Project. Each plan item covers a feature or API that is to be added to the e4 Project deliverables, or some aspect of the e4 Project that is to be improved. Each plan item has 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 entails.

Although there are several components under the e4 project, there is a significant amount of commonality and shared effort between them. In general, many plan items involve coordinated changes to multiple components, and thus attempting to separate the items into sections based on sub-project leads to artificial distinctions between them. As such, this plan covers the work of all components under the e4 Project.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order. See the corresponding bugzilla items for up-to-date status information on ongoing work and planned delivery milestones.

The current status of each plan item is noted:

• Committed plan item - A committed plan item is one that we have decided to address for the release. In bugzilla, this is reflected by having a concrete target milestone assigned.
• Proposed plan item - A proposed plan 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. In bugzilla, such items are reflected by having a target milestone "1.0" assigned.
• Deferred plan item - 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. In bugzilla, such items are reflected by having no target milestone assigned.