Re: [gef-dev] GEF4 0.3.0 vs. 1.0.0, GitHub migration

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxxxxxxxx>]

Hi,

first of all, thank you for your great work. I myself still have not lived up to my promise to fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=433529, so I feel somewhat guilty, about making you do the extra work with 0.3.0. Sorry. :)

If you feel the codebase is mature enough, lets go for 1.0.
——

About Github vs Gerrit: I have worked with both on different projects for some time, and the thing is, both suggest very different workflows. Gerrit asks everything to be reviewed, and then the final, cleaned-up version goes into the repository; in case of Github pull requests you add new commits to the branch (otherwise all comments for the previous branch will be lost), thus a series of commits gets merged.

I personally like the Gerrit approach better, but it requires some time getting used to. I guess, this is why most of my collegues like Github better (and so probably other possible contributors as well). 

In short: I have mixed feelings, but am ok with both. Furthermore, it seems I am not the one doing most work, so the preference shouldn’t be mine. :)

Cheers,
Zoltán
-- Zoltán Ujhelyi

Technology Expert
IncQueryLabs Ltd.

> On 22 Jan 2016, at 17:33, Alexander Nyßen <nyssen@xxxxxxxxx> wrote:
> 
> 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
> 
> 
> 
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/gef-dev