|Re: [tools-pmc] [gef-dev] Draw2d/GEF 4.0|
I really wanted to send a more detailed response, but before we start anything, we need to know in detail, hopefully already tracked by Bugzilla:
1) All the functional changes being requested that require a GEF 4.0 / Draw2d 4.0.
2) How much of GEF / Draw2d would be expected to change.
3) How the backwards compatibility layer would work.
With regards to (3), again, I wanted to make a complete response, but the expectation is and will be that all existing plugins using 3.x API will be provided a compatibility later to work with GEF 4.0 / Draw2d 4.0. This is the same level of compatibility delivered with the Eclipse Platform for both their 3.0.0 and 4.0.0 releases, I expect no less from GEF / Draw2d.
Date: 04/05/2011 12:20 PM
From: Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
To: GEF development <gef-dev@xxxxxxxxxxx>,
Cc: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>
Subject: Re: [gef-dev] Draw2d/GEF 4.0
Sent by: gef-dev-bounces@xxxxxxxxxxx
http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
2011/3/22 Alexander Nyßen <alexander.nyssen@xxxxxxxxx>
I had tried to start a discussion on whether to have a new major version of Draw2d and GEF in 2012 here recently. As there has not been much response yet, let me clarify what I was referring to in detail, because that could probably have been misunderstood.
Sorry for not responding earlier. Don't take that as a sign that I think this is a bad idea. In fact, I think what you are proposing is exactly what we need in GEF!
I haven't looked at the specific API problems you've mentioned below, but an API that doesn't allow GEF to evolve to meet the needs of the current committers (and presumably a portion of the user community) is a problem. Especially if SWT has released new API, some of which we cannot consume with our current design.
While I would thus like to have the chance of adjusting our current API, I see two important arguments that cannot be neglected:
1) we need to provide long-term support for our clients. This implies that - as GEF has been API-stable for quite some time now - we cannot simply come up with a 4.0 revision in 2012 without having announced it in advance and having given our long-term clients the chance to transition to it.
2) we most likely cannot achieve to incorporate all changes in a 6-9 month timeframe, so introducing a 4.0 version as a replacement for 3.7 in 2012 would be no good option from this viewpoint either. Being a replacement, we would have to fix its API again and would - to incorporate all changes - probably have to come up with additional major releases shortly afterwards.
Right, I don't think it makes sense to do all the work in a single 'release'.
Personally, I would follow the same pattern as e4 / Eclipse 4.x. Start the work in an incubator and see how it unfolds. By performing the work in an incubator we are not binding ourselves to any API, we can take advantage of parallel IP, we could break/change some of the existing development methods (release schedules, scm systems, etc...). If the work didn't evolve to a usable state, then we can simply archive it; and if it did reach a level of maturity that we are comfortable supporting, then we could role it into GEF proper.
As I mentioned, this model has worked well for e4/Eclipse 4.x. We've also used this same model in p2.
Unfortunately, we proposed an incubator project  last year and it was determined that there is no clear advantage [2,3]. So I'm raising this with the PMC again with a clear question: "We have some existing committers, and possibly new ones (I don't know) who are interested in experimenting with a new GEF API, what is the best way to proceed?"
Should we simply fork the bundles into a new project and let the committers work there? If we do this in GEF proper what does this portray to our user community (are we saying the work is 'release quality')?
Dr. Alexander Nyßen
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
Am Brambusch 15-24
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
gef-dev mailing list
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
gef-dev mailing list
gef-dev mailing list
Back to the top