Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "GEF/GEF4"
(New page: == Motivation == As agreed on in Bugzilla [https://bugs.eclipse.org/bugs/show_bug.cgi?id=347636 347636], GEF 4.0 API will be started in parallel to the current GEF 3.x development branch u...) |
(→Motivation) |
||
| Line 6: | Line 6: | ||
located next to Zest 2.0, so that all experimental GEF components can be found | located next to Zest 2.0, so that all experimental GEF components can be found | ||
in one place). | in one place). | ||
| − | |||
# The experimental branch created thereby will live parallel to the GEF HEAD | # The experimental branch created thereby will live parallel to the GEF HEAD | ||
branch, considering all its API as provisional unless explicitly graduated. It | branch, considering all its API as provisional unless explicitly graduated. It | ||
| Line 12: | Line 11: | ||
separate wiki pages for documentation of the ongoing work (similar to Zest | separate wiki pages for documentation of the ongoing work (similar to Zest | ||
2.0). | 2.0). | ||
| − | |||
# Committers working on the experimental branch will be responsible for | # Committers working on the experimental branch will be responsible for | ||
ensuring fixes made to GEF HEAD also get applied to the experimental branch. | ensuring fixes made to GEF HEAD also get applied to the experimental branch. | ||
| − | |||
# Graduation of the experimental branch back into GEF HEAD will have to imply | # Graduation of the experimental branch back into GEF HEAD will have to imply | ||
that a proper compatibility layer is in place so all GEF 3.x clients run in a | that a proper compatibility layer is in place so all GEF 3.x clients run in a | ||
100% binary compatible method. It will furthermore have to be acknowledged by | 100% binary compatible method. It will furthermore have to be acknowledged by | ||
all GEF committers. | all GEF committers. | ||
| − | |||
# Work will start without an incubator project at first, granting commit | # Work will start without an incubator project at first, granting commit | ||
rights on the Git repository to all current GEF committers. The question of | rights on the Git repository to all current GEF committers. The question of | ||
Revision as of 10:50, 21 October 2011
Motivation
As agreed on in Bugzilla 347636, GEF 4.0 API will be started in parallel to the current GEF 3.x development branch under the following terms:
- After the Indigo release has been completed, a GEF experimental branch is
created by forking the GEF 3.7 code-base into a Git repository (possibly located next to Zest 2.0, so that all experimental GEF components can be found in one place).
- The experimental branch created thereby will live parallel to the GEF HEAD
branch, considering all its API as provisional unless explicitly graduated. It will not interfere with GEF HEAD, i.e. it will have its own build process and separate wiki pages for documentation of the ongoing work (similar to Zest 2.0).
- Committers working on the experimental branch will be responsible for
ensuring fixes made to GEF HEAD also get applied to the experimental branch.
- Graduation of the experimental branch back into GEF HEAD will have to imply
that a proper compatibility layer is in place so all GEF 3.x clients run in a 100% binary compatible method. It will furthermore have to be acknowledged by all GEF committers.
- Work will start without an incubator project at first, granting commit
rights on the Git repository to all current GEF committers. The question of introducing an incubator project (located under GEF) will be deferred until a) community wants to actively get involved or b) Juno has been released (whatever comes first).
As migration of GEF to git has not been completed yet (see Bugzilla 351232 for details), development has been started by creating a new Geometry API, based on the current Draw2d geometry classes (see Bugzilla 355997 for details). Due to the lessons learned in developing an initial GEF 4 Geometry API, and due to the compatibility requirements imposed on a gradation of the new GEF4 API, it was concluded that migrating the existing code base on a module-per-module basis is more appropriate than branching the whole code base. The completion of the GEF4 Geometry API will be the first package that is to be completed with respect to this. Based on the Geometry API, other packages may then be investigated, as outlined in the Roadmap below.
Components / Roadmap
- GEF4 Geometry - Q4 2011
- Draw2d Core (Graphics, Canvas, Figure, Bounds, etc.)