| [gef-dev] GEF4 0.3.0 vs. 1.0.0, GitHub migration |
| Hi team, first, as Neon M5 is coming nearer (February 1st) its time to finalize our decision about whether we are going to contribute GEF4 1.0.0 or 0.3.0 to Neon (we had decided to postpone the final decision up to M5). Matthias and I have worked very intensively on cleaning up our provisional API (compared to 0.2.0 we have touched almost all of it to some extent) and I am quite satisfied with our progress. With the adoption of JavaFX properties (see 484774), which we finalized this week, we have completed the last major API change that was on the list, except for the refactoring of the Cloudio and Zest JFace APIs, which should have to be polished up to M6. While some minor adjustments may still be needed in other places as well, the API should now be in quite a good shape already. As such, I would like to contribute 1.0.0 for Neon, opening up our provisional API, for two reasons: 1) I think it is time for a clear signal to our adopters that GEF4 has reached a certain maturity and that we want people to start adopting it. Those that have already started to adopt it gave us valuable feedback that helped to improve the code base a lot. Even if we decide to come up with a 2.0.0 release for Neon +1 (which I would like to do), I would not like to postpone this signal by another year. 2) I want to be able to guarantee strict semantic versioning to our adopters, using API tooling. Up to now, this is not possible, because no API is yet published. This leads to problems: our 0.2.0 release is e.g. not compatible to our 0.1.0 release because we broke provisional API, yet the versioning indicates compatibility; we did not contribute it 0.2.0 to the simrel repo for Mars.1 because of this, which caused some confusion). I would rather contribute a 2.0.0 release directly after the 1.0.0 than violating OSGi compatibility. Therefore, if nobody objects, I would plan to open up the API (and change our bundle versions from 0.3.0 to 1.0.0) after M5, so that we could finalize it up to M6 as planned (i.e we could contribute a 0.3.0 with M5 and then switch to 1.0.0 for M6). Second, we had discussed earlier about a potential Gerrit adoption. The idea behind this discussion was to ease things for our contributors. With the (not very convincing) experiences I have made with Gerrit so far and the current „opening up“ of the foundation with respect to GitHub, I would alternatively propose a migration to GitHub. Compared to Gerrit, GitHub IMHO makes it much easier for adopters to contribute (I have experienced that myself with Xtext and other non-Eclipse projects). As GitHub issues can now also be used in alternative to Bugzilla, a nicer integration could be used, and our HIPP infrastructure should still be usable as well. Also, as we support building up standalone graphical applications (independent of Eclipse UI) with GEF4, GitHub could be a better place to broaden our community. While the foundation wants projects to migrate on an all-or-nothing basis, I would like to rule out if there is the possibility of an exception, as I would rather leave GEF 3.x and the related issues on the Eclipse.org infrastructure. But I want your opinions first. Comments are thus welcome! Cheers Alexander -- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer Telefon: +49 (0) 231 / 98 60-202 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: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail