Jump to: navigation, search

Difference between revisions of "GEF/GEF4"

< GEF
(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 09: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:

  1. 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).

  1. 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).

  1. Committers working on the experimental branch will be responsible for

ensuring fixes made to GEF HEAD also get applied to the experimental branch.

  1. 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.

  1. 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.)