Overview

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

This document lays out the feature and API set for the next feature release of the Eclipse M2T project, designated release 1.0.

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.

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 the components under the Eclipse MDT project.
Each plan item covers a feature or API that is to be added, or some aspect 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 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.

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.

Thus 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 into 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.

Release deliverables

The release deliverables are:

M2T Core component

Source code release, available as versions tagged "R1_0" in the org.eclipse CVS repository

Downloadable distributions of the binary runtime and SDK

Eclipse Update Site distributions of the binary runtime and SDK.

M2T Shared component

Source code release, available as versions tagged "R1_0" in the org.eclipse CVS repository

Downloadable distributions of the binary runtime and SDK

Eclipse Update Site distributions of the binary runtime and SDK.

JET component

Source code release, available as versions tagged "R1_0" in the org.eclipse CVS repository

Downloadable distributions of the binary runtime and SDK

Eclipse Update Site distributions of the binary runtime and SDK.

Xpand component

Source code release, available as versions tagged "R1_0" in the org.eclipse CVS repository

The 1.0 release is targeted for June 30, 2008.
All release deliverables will be available for download as soon as the release has been tested and validated in the target operation configurations listed below.

Target operating environments

In order to remain current, each release of an Eclipse project targets reasonably current versions of underlying operating environments and other Eclipse projects on which it depends.

Most of Eclipse is "pure" JavaTM code and has no direct dependence on the underlying operating system. The chief dependence is on the Eclipse Platform, and on the Java 2 Platform that runs it.

The M2T 1.0 release depends on the following:

Java 2 Platform 1.4, or later

Eclipse Platform 3.2, or later

EMF 2.2, or later

The M2T platform is designed to run on any configuration supporting the above components.

The Eclipse Platform runs in a variety of operating environments. Testing is focused on a handful of popular combinations of operating system and Java 2 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.

Compatibility with previous releases

M2T Core component

API Contract Compatibility: New component, contract compatibility is not applicable.

Binary (plug-in) Compatibility: New component, binary compatibility is not applicable.

Source Compatibility: New component, Source compatibility is not applicable.

Workspace Compatibility: New component, Workspace compatibility is not applicable.

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

M2T Shared component

API Contract Compatibility: New component, contract compatibility is not applicable.

Binary (plug-in) Compatibility: New component, binary compatibility is not applicable.

Source Compatibility: New component, Source compatibility is not applicable.

Workspace Compatibility: New component, Workspace compatibility is not applicable.

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

JET Component

API Contract Compatibility:
JET 1.0 will be upwards contract-compatible with JET 0.8 expect in those areas noted in the JET 1.0 Migration Guide.
Programs that us affected APIS and extension points will need to be ported to JET 1.0 APIs.
Downward contract compatibility is not supported.
There is no guarantee that complies with the JET 1.0 APIs will ensure complies with the JET 0.8 APIs.
Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility:
JET 1.0 will be upwards binary-compatible with JET 0.8 expect in those areas noted in the JET 1.0 Migration Guide.
Downward plug-in compatibility is not supported: plug-ins compiled against JET 1.0 will likely be unusalbe with JET 0.8.
Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility:
Sources files written to the JET 0.8 APIs will usually compile and run successfully against the JET 1.0 APIs, although this cannot be guaranteed.
In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations.
Downward source compatibility is not supported.
If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility:
JET 1.0 will be upwards workspace-compatible with JET 0.8 unless noted.
This means that workspaces and projects created by an Eclipse with JET 0.8 installed can be successfully opened by an Eclipse with JET 1.0 installed.
This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories.
User interface session state may be discarded when a workspace is upgraded.
Downward workspace compatibility is not supported.
Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

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

XPand Component

API Contract Compatibility:
XPand X.Y will be upwards contract-compatible with XPand X.Y-1 expect in those areas noted in the XPand X.Y Migration Guide.
Programs that us affected APIS and extension points will need to be ported to XPand X.Y APIs.
Downward contract compatibility is not supported.
There is no guarantee that complies with the XPand X.Y APIs will ensure complies with the XPand X.Y-1 APIs.
Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility:
XPand X.Y will be upwards binary-compatible with XPand X.Y-1 expect in those areas noted in the XPand X.Y Migration Guide.
Downward plug-in compatibility is not supported: plug-ins compiled against XPand X.Y will likely be unusalbe with XPand X.Y-1.
Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility:
Sources files written to the XPand X.Y-1 APIs will usually compile and run successfully against the XPand X.Y APIs, although this cannot be guaranteed.
In some cases, it may be necessary to make minor changes to the source code to disambiguate things like imports or overloaded method invocations.
Downward source compatibility is not supported.
If source files use new APIs, they will not be usable with earlier versions.

Workspace Compatibility:
XPand X.Y will be upwards workspace-compatible with XPand X.Y-1 unless noted.
This means that workspaces and projects created by an Eclipse with JET 0.7 installed can be successfully opened by an Eclipse with XPand X.Y installed.
This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project, which may propagate between workspaces via file copying or team repositories.
User interface session state may be discarded when a workspace is upgraded.
Downward workspace compatibility is not supported.
Metadata files created (or overwritten) by the newer version will generally be unusable with older versions.

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