Difference between revisions of "GMF Project Plan"
m (→Plan Item Queries)
m (→2.0 Themes)
|Line 96:||Line 96:|
==== 2.0 Themes ====
==== 2.0 Themes ====
Taking into consideration the [http://www.eclipse.org/org/councils/roadmap_v2_0/themes_v2_0.php themes] provided by the Requirements Council, overall Modeling project [[Modeling Project Plan themes]] and the GMF 1.0 release state and community feedback, the following themes are planned to be addressed in the 2.0 release:
Taking into consideration the [http://www.eclipse.org/org/councils/roadmap_v2_0/themes_v2_0.php themes] provided by the Requirements Council, overall Modeling project [[Modeling Project Planthemes]] and the GMF 1.0 release state and community feedback, the following themes are planned to be addressed in the 2.0 release:
===== API =====
===== API =====
Revision as of 08:25, 10 August 2006
Graphical Modeling Framework 2.0 Plan (Draft)
Last revised 1731 EST August 07, 2006
- 1 Introduction
- 2 Release deliverables
- 3 Release milestones
- 4 Maintenance Stream
- 5 Target Operating Environments
- 6 Internationalization
- 7 Compatibility and Dependencies
- 8 API Contract
- 9 Features and Capabilities
This document lays out the feature and API set for the second release of the Eclipse Graphical Modeling Framework Project, version 2.0.0.
This project plan and associated requirements are the result of an open and transparent process and includes input from those who have expressed an interest in the project. That said, the success of the project and its deliverables is soley dependent upon the contributions from its community membership. If you are interested in contributing to the project in the delivery of its stated goals, you are more than welcome!
The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, compatibilities and dependencies. 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 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.
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 is found in most Eclipse projects, namely:
- Graphical Modeling Framework source code release, available as versions tagged "R2_0" in the project's CVS repository.
- Graphical Modeling Framework SDK (includes runtime and tooling components, with sources, examples, and documentation) (downloadable and update site).
- Graphical Modeling Framework runtime binary distribution (downloadable and update site).
- Graphical Modeling Framework tests (downloadable and update site).
Release milestone occurring at roughly 6 week intervals and follow the Platform milestone releases by approximately 2 weeks; that is, until the final 3.3 release of the Platform, upon which GMF and other projects will release simultaneously. As GMF is dependent upon the EMF, GEF, and other projects, which are scheduled to release milestones within 1 week of Platform milestones, GMF will deliver its milestones within the following week. It is anticipated that GMF will synchronize its release milestones with the Europa release schedule. The milestones are:
- Friday August 25, 2006 - Milestone 1 (2.0 M1) - stable build, tagged M1_20 in CVS
- Friday Mmm XX, 200X - Milestone 1 (2.0 M2) - stable build, tagged M2_20 in CVS
- Friday Mmm XX, 200X - Milestone 1 (2.0 M3) - stable build, tagged M3_20 in CVS
- Friday Mmm XX, 200X - Milestone 1 (2.0 M4) - stable build, tagged M4_20 in CVS
- Friday Mmm XX, 200X - Milestone 1 (2.0 M5) - stable build, tagged M5_20 in CVS (API freeze)
- Friday Mmm XX, 200X - Milestone 1 (2.0 M6/RC0) - stable build, tagged M6_20 in CVS
Lock down and testing then begins with M6, and progress through a series of test-fix passes against candidates releases. Release candidate builds are planned as follows (M6 is release candidate 0):
- Friday Mmm XX, 200X - Release Candidate 1 - (2.0 RC1)
- Friday Mmm XX, 200X - Release Candidate 2 - (2.0 RC2)
- Friday Mmm XX, 200X - Release Candidate 3 - (2.0 RC3)
- Friday Mmm XX, 200X - Release Candidate 4 - (2.0 RC4)
- Friday Mmm XX, 200X - Release Candidate 5 - (2.0 RC5)
- Friday Mmm XX, 200X - Release Candidate 6 - (2.0 RC6)
As these milestones are dependent upon the Platform, they may be altered in order to conform to the published plan. 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.
GMF 1.0.1 and 1.0.2 maintenance releases are anticipated, to align with the release of the Platform 3.2.1 (Q306) and 3.2.2 (Q107) releases, respectively. A list of issues indicated for the 1.0.x maintenance stream can be found here: 1.0.1 and 1.0.2.
Target Operating Environments
In order to remain current, each Eclipse release targets reasonably current versions of the underlying operating environments.
The Eclipse Graphical Modeling Framework (GMF) project depends upon on the Platform and other projects, which are mostly "pure" Java. The 3.3 release of the Eclipse Platform Project is written and compiled against version 1.4 of the Java Platform APIs, and targeted to run on version 1.4 of the Java Runtime Environment, Standard Edition. The Eclipse Modeling Framework (EMF) project has declared to support Java 5 language features in its next release (3.3.0), and will therefore require a Java 5 runtime environment. GMF will target the same Java version as EMF.
Eclipse Platform SDK 3.3 will be tested and validated on a number of reference platforms. GMF will be tested and validated against a subset of those listed for the platform. Those available will be presented on the project download site.
The Eclipse Platform 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. As a result, the Graphical Modeling Framework project will provide English strings in its default bundles and be localized to a subset of those locales offered by the Platform. This plan will be updated to indicate which locales will be provided and the timeframe for availability.
Compatibility and Dependencies
Compatibility of Release 2.0
The Graphical Modeling Framework Project will be developed in parallel, and released simultaneously, with the following projects. As stated above, each milestone release of the Graphical Modeling Framework Project will be compatible with the corresponding milestones for each of these projects, and delivered the appropriate offset.
- Eclipse Platform SDK version 3.3
- Eclipse Modeling Framework (EMF) version 3.0
- Graphical Editing Framework (GEF) version 3.3
Therefore, the Graphical Modeling Framework initial release will be compatible with these versions and will publish binary and source compatibilities with migration guides on subsequent releases.
It is a goal of the Graphical Modeling Framework Project to avoid provisional APIs. APIs published for the 2.0 release will be carefully reviewed prior to release, making use of "internal" packages for unsupported and variable implementation classes. Client plug-ins that directly depend on anything other than what is specified in the published API are inherently unsupportable and receive no guarantees about future compatibility. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins. Note that GMF follows the posted Version Numbering guidelines.
Compatibility of Release 2.0.0 with 1.0.0
GMF 2.0.0 will be compatible with GMF 1.0.0, except in those areas noted in the GMF 2.0.0 Migration Guide.
=====API Contract Compatibility:===== GMF 2.0.0 will be upwards contract-compatible with GMF 1.0.0 except in those areas noted in the GMF 2.0.0 Migration Guide. Programs that use affected APIs and extension points will need to be ported to GMF 2.0.0 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with GMF 2.0.0 APIs would ensure compliance with GMF 1.x APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.
=====Binary (plug-in) Compatibility:===== GMF 2.0.0 will be upwards binary-compatible with GMF 1.0.0 except in those areas noted in the GMF 2.0.0 Migration Guide. Downward plug-in compatibility is not supported: plug-ins compiled against GMF will likely be unusable with GMF 1.x. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.
=====Source Compatibility:===== Source files written to use GMF 1.0.0 APIs will usually compile and run successfully against GMF 2.0.0 APIs, although this cannot be guaranteed. Because GMF 2.0.0 will exploit new Java language constructs, there is an increased chance of source incompatibilities compared to previous GMF releases. 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:===== GMF 2.0.0 will be upwards workspace-compatible with GMF 1.0.0 unless noted. This means that workspaces and projects created by an Eclipse with GMF 1.0.0 installed can be successfully opened by an Eclipse with GMF 2.0.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-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 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 or Provisional API Guidelines for information about how to write compliant plug-ins.
GMF 2.0.0 Migration Guide
At this time, there are no known issues migrating from 1.0.0 to 2.0.0. Should this change, this document will be revised, or a secondary document will be added documenting any known issues.
Features and Capabilities
A list of project requirements and agreed upon implementation timeframes is found in this document. For the milestones listed in this document, a set of overall themes is used to indicate what major set of functionalities is to be concentrated on for each. These themes are presented below, while the requirements document and associated Bugzilla entries are left to those wanting more detailed information on each.
Taking into consideration the themes provided by the Requirements Council, overall Modeling project themes and the GMF 1.0 release state and community feedback, the following themes are planned to be addressed in the 2.0 release:
A number of items related to the GMF API are planned to be addressed, including the addition of new APIs, refactoring of old APIs, and improved API documentation. A list of those plan items related to API (keyword=api) can be found here.
A number of usability items related to runtime and tooling components of GMF are found in this section. A list of those plan items related to Usability (keyword=usability) can be found here.
As a project within the Eclipse Modeling Project, a number of build dependency and interoperability items exist with other Modeling projects. A number of releng tasks and support of GMF's use in providing UML2 diagramming are anticipated to be addressed in the 2.0 release timeframe. Furthermore, as GMF 2.0 is scheduled to release with the Europa simultaneous release, along with other Modeling projects, some coordination and requirements for being on the release train is also anticipated.
A number of performance issues have been identified and will be worked during the 2.0 timeframe. A list of those plan items related to Performance (keyword=performance) can be found here.
Plan items reflect new features of the GMF project, or areas where existing features will be significantly reworked. Plan items are indicated using keywords and have a state determined by 'Assigned To' and 'Target Milestone' fields in Bugzilla. Below is a list of possible states and what they mean:
- Committed items - A committed bug is one that we have decided to address for the release.
- Proposed items - A bug 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 items - 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.
Plan Item Queries
Bugzillas with a target milestone and developer assigned are considered committed in that release. For the most current list of these items for the 2.0.0 release, see the following links:
Bugzillas without an assigned developer are proposed, but not committed for a particular release. For the most current list of these items, see the following links:
Bugzillas with an unspecified target milestone are deferred, and not scheduled for the current release. For the most current list of these items, see the following link: