| Re: [tools-pmc] GEF4 provisional component |
| David, please find my comments below. Am 14.02.2012 um 02:51 schrieb David M Williams:
Anthony and I have discussed and agreed on all "terms" regarding the GEF4 provisional component already. As stated on the bug, we have started the enterprise in terms of a provisional sub-component (which technically is placed in its own Git component) that may later be transferred into an incubator sub-project (when community interest grows) and at some point in time also be graduated to replace GEF 3.x (which will only be done as far as we also have a compatibility layer for 3.x ready in place). As this is currently quite far away, GEF 3.x and GEF4 will have to live next to each other for quite some time, which implies that there may be the wish to include them both in a single distribution without collision. That's the reason I introduced the org.eclipse.gef4 namespace and the concern of my question. I am sorry if the PMC is the wrong location to ask such kind of things, but as it thought it to be a question probably without the scope of the GEF project alone, I thought this to be the right place. BTW, GEF also uses the org.eclipse.draw2d and org.eclipse.zest namespaces, which seem to be out of the project scope either...
Well, I thought to start with sort of a "branch" and let it evolve. What has been done so far is to work on a "new" (API incompatible) geometry API. After we have released Juno, my plans are to transfer the other parts of the current 3.8 code (while already porting it to the new geometry api) and then start to refactor the API there, beginning also to integrate new features. So, no, its not going to be the same except for some additions...
The goal is indeed to evolve GEF without any restrictions on its current API. That may indeed lead to "incompatible" changes. I think it is more or less a question about what we understand about evolution. Especially Draw2d will probably have to change significally. Other things are e.g. the command framework within GEF, that can be reconsidered. There are several other points. However, the goal of the sub-component respectively sub-project is to evolve GEF into something modern and better usable, so setting it up as a new project does not seem to be appropriate from my point of view.
Well, Anthony and I have already agreed on this, as stated on the bug. GEF 3.x will continue as it is (i.e. no API breaking changes) and GEF4 will have the chance to develop without being bound to API compatibility. Actually that's the reason we started the provisional component. As already said, creating an incubator sub-project would be the next logical step after having sep up the provisional component. However, I did not want to discuss the decision whether we are going to do this step or not here (that's indeed between Anthony and me), I simply wanted to know what would have to be done from an organizational viewpoint. If this is not the right place for such kind of questions, I apologize.
Cheers, Alexander
-- Dr. Alexander Nyßen
Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nyssen@xxxxxxxxx itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: 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 |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail