Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
4.0.0
Last revised 10:00 ET July 20, 2010.
Please send comments about this plan to theeclipse-dev@eclipse.orgdeveloper mailing list.
This document lays out the feature and API set for the next feature release of the Eclipse SDK after 3.6, designated release 4.0. This is a special release of the Eclipse project, whose only goal is to adopt technology from the e4 incubator while maintaining full API compatibility with previous releases. There are very few new features for end users in this release, and no changes at all in the JDT and PDE sub-projects. The end result will be a release with a similar feature set to the Eclipse project 3.6 (Helios) release, but with a brand new implementation of the platform user interface under the covers. Since this is effectively a 1.0 release of this new implementation, we expect it to be a bit rough around the edges, with slightly less polish than earlier releases built on the old workbench technology.
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 Eclipse Project PMC) 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 sub-projects under the top level Eclipse Project. Each plan item covers a feature or API that is to be added to the Eclipse Project deliverables, or some aspect of the Eclipse 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 SDK. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order.
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.
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.