1) As Ian already said, I don't think that we cannot foresee all functional changes now. But I think we have a Bugzilla backlog that can serve as a very good starting point for an investigation (I think most of the issues that I had in mind are already covered by one or another bug there). I already started to assign some bugs to the "Future" milestone, to indicate that API-breaking changes would be needed to resolve them. If we introduce a 4.0 milestone to bugzilla, I could offer to start with a more thorough triaging with respect to this.
2) I think most of what I had in mind when proposing the branch is already covered by bugs in our backlog (there are some quite fundamental issues). Everything that is not present already could be filed and assigned to a 4.0 milestone as well.
3) I am open for a discussion on this one. Anthony, could you elaborate what your ideas are w.r.t. this point?
I am not sure what would be the best option from an organizational viewpoint, a branch or an incubator. From a technical one, a branch would probably be sufficient. Whatever we do, I think it would be good to include Zest 2.0 to have all "experimental" GEF components in one place. And I do not think it would be the right message to our community to leave the Eclipse.org boundaries...
Cheers, Alexander Am 05.04.2011 um 19:49 schrieb Ian Bull:
On Tue, Apr 5, 2011 at 10:27 AM, Anthony Hunter <anthonyh@xxxxxxxxxx> wrote:
Hi Team,
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.
So this is the Chicken-and-egg problem that continues to plague us. We can't start anything until we know 'in detail' how it will work. And we likely won't know much in detail until we start.
These are arguably fine criteria for 'shipping' or 'declaring API' -- I say arguably because I think we could argue against these too -- but is it true that these criteria must be met before anybody begins working?
This is exactly my reasoning for an incubator. We could set these out as 'must dos' before the incubator is graduated, but let Alexander (and others) experiment in the meantime. David mentioned doing this in a branch, and I'm fine with that too -- although with the foundation's transition to git I think we should likely fork the code and use git instead.
All I'm looking for is a tool to let Alexander (and others) experiment with different ideas within the legal (and technical) boundaries of eclipse.org. The messaging I would like to convey to our users is: This is experimental work, and even if it does come to fruition, it likely won't happen for some time. Moreover, we are unlikely to stop shipping the 3.x version of GEF / Draw2d even after the 4.x stuff is generally available.
Maybe this sort of experimental development is not easily supported by the Eclipse Development Process and the git-hub mirrors are the recommended approach.
Cheers, Ian
Cheers...
Anthony
Date:
04/05/2011 12:20 PM
Subject:
Re: [gef-dev]
Draw2d/GEF 4.0
Sent by:
gef-dev-bounces@xxxxxxxxxxx
2011/3/22 Alexander Nyßen <alexander.nyssen@xxxxxxxxx>
Hi all,
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 [1] 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?"
[1] http://wiki.eclipse.org/Gef/Incubator/Proposal
[2] http://dev.eclipse.org/mhonarc/lists/tools-pmc/msg01184.html
[3] http://dev.eclipse.org/mhonarc/lists/tools-pmc/msg01187.html
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')?
cheers,
ian
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
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com
| http://twitter.com/eclipsesource_______________________________________________ _______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev
-- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ gef-dev mailing list gef-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/gef-dev
-- 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
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
|