This document lays out the feature and API set for the next feature release
of the Eclipse SDK after 4.7, designated release 4.8 and code-named Photon.

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 release deliverables have the same form as previous releases, namely:

Source code release for all Eclipse Project deliverables, available as
versions tagged "R4_8" in the Eclipse Project Git
repositories.

Our target is to complete 4.8 in late June 2018, in alignment with Photon.
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.

PMC approval is required for API changes and additions after M6.

Dates for builds and test passes after M7 will be available in the
Eclipse 4.8 Endgame Plan.

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

Most of the Eclipse SDK 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. Java 5, Java 6, etc).

In general, the 4.8 release of the Eclipse Project is developed on Java SE 8 VMs.
As such, the Eclipse SDK as a whole
is targeted at all modern, desktop Java VMs. Most functionality is available for
Java SE 8 level development everywhere, and extended development capabilities are made
available on the VMs that support them.

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.

Eclipse 4.8 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 Eclipse 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.

The Eclipse SDK is designed as the basis for internationalized products. The
user interface elements provided by the Eclipse SDK components, including dialogs
and error messages, are externalized. The English strings are provided as the
default resource bundles.

Latin-1, DBCS, and BiDi locales are supported by the Eclipse SDK on all reference platforms.

Compatibility of Release 4.8 with 4.7

Eclipse 4.8 will be compatible with Eclipse 4.7 (and all earlier 3.x versions).

API Contract Compatibility: Eclipse SDK 4.8 will be upwards
contract-compatible with Eclipse SDK 4.7 except in those areas noted in the
Eclipse 4.8 Plug-in Migration Guide. Programs that use affected APIs and extension points will need to be ported
to Eclipse SDK 4.8 APIs. Downward contract compatibility
is not supported. There is no guarantee that compliance with Eclipse SDK 4.8
APIs would ensure compliance with Eclipse SDK 4.7 APIs. Refer to
Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: Eclipse SDK 4.8 will be upwards
binary-compatible with Eclipse SDK 4.7 except in those areas noted in the
Eclipse 4.8 Plug-in Migration Guide. Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK
4.8 will not be usable in Eclipse SDK 4.7. Refer to
Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Eclipse SDK 4.8 will be upwards source-compatible
with Eclipse SDK 4.7 except in the areas noted in the
Eclipse 4.8 Plug-in Migration Guide. This means that source files written
to use Eclipse SDK 4.7 APIs might successfully compile and run against Eclipse
SDK 4.8 APIs, although this is not guaranteed. Downward source compatibility
is not supported. If source files use new Eclipse SDK APIs, they will not be
usable with an earlier version of the Eclipse SDK.

Workspace Compatibility: Eclipse SDK 4.8 will be upwards
workspace-compatible with earlier 3.x and 4.x versions of the Eclipse SDK unless noted.
This means that workspaces and projects created with Eclipse SDK 4.7, 4.3, .. 3.0 can be successfully
opened by Eclipse SDK 4.8 and upgraded to a 4.8 workspace. This includes both
hidden metadata, which is localized to a particular workspace, as well as metadata
files found within a workspace project (e.g., the .project file), which may
propagate between workspaces via file copying or team repositories. Individual
plug-ins developed for Eclipse SDK 4.8 should provide similar upwards compatibility
for their hidden and visible workspace metadata created by earlier versions;
4.8 plug-in developers are responsible for ensuring that their plug-ins recognize
metadata from earlier versions and process it appropriately. User
interface session state may be discarded when a workspace is upgraded. Downward
workspace compatibility is not supported. A workspace created (or opened) by
a product based on Eclipse 4.8 will be unusable with a product based on an earlier
version of Eclipse. Visible metadata files created (or overwritten) by Eclipse
4.8 will generally be unusable with earlier versions of Eclipse.

Non-compliant usage of API's: All non-API methods and classes,
and certainly everything in a package with "internal" in its name or
x-internal in the bundle manifest entry,
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 SDK 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.

We no longer group the plan items into separate themes as this is does not provide real value to our users.

Each plan item listed in the sub-project plans 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 entails.

Although there are three mature projects under the top-level Eclipse 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 (e.g., Platform UI vs. JDT UI, Platform
Debug vs. JDT Debug, etc.). As such, this plan covers the work of all mature sub-projects
under the top level Eclipse 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.