Re: [cross-project-issues-dev] GEF participation in Neon

[Alexander Nyßen <nyssen@xxxxxxxxx>]

Hi David, please find my comments below.

Am 24.08.2015 um 14:49 schrieb David M Williams <david_williams@xxxxxxxxxx>:

Thanks Alexander, for letting us know. I myself won't object to your "M5" timing, and since is for GEF4 (not GEF in general) I suspect all is fine, either way.

But, I wanted to remind you, and the whole "extended team", that it is best to settle these issues as soon as possible. The reason is that some (many?) projects like  (or need) to support running on more than one version of Eclipse (such as current -1, or a few even do current -2).  For those projects, if they used GEF 4, they *might* need to do something special to handle such a change  ... so ... for them, the earlier they know, the better they can react OR, perhaps, even change their plans (and then they have to let their adopters know too, etc.)

As stated, we want to take that decision with M5 at the latest, which is well before API and feature freeze. There are a couple of themes we want to address (see https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon/plan), and the decision will be mostly based on the progress and results achieved there.

Would your change from "0" to "1" reflect "breaking API" (such as, would you be renaming packages from "provisional" or "internal" to be true "API packages"? Or, does the versioning just reflect whether or not you've graduated?

GEF4 is not in incubating state, its not even a sub-project of GEF. Technically speaking, all GEF4 components are pure provisional API of the GEF project (i.e. all exported GEF4 packages are currently guarded by x-internals or x-friends). We have decided to use the 0.x versions for the GEF4 bundles and features only to indicate that there is no public API yet (and that breaking changes of the provisional API might occur between minor revisions, which already happened between 0.1.0 and 0.2.0). For Neon, we will break (provisional) API in either case, even if we decide to only publish 0.3.0. The step from „0“ to „1“ would basically mean that we decide to turn some or all of our provisional API into public API (i.e. remove the x-internals). 

Again, for your case, I doubt it would matter (too much :), but I thought best to explicitly document how "major" increases can impact others in ways that some might not be aware of. Not everyone is concerned with "just the current release".

I personally think "graduation" is not too related to the "state of your code", but more to your ability to demonstrate you are a self running project, with some adopters, involved with community, etc. So, for example, even if you publish "1.x" with what ever you have, if you decide to make breaking API changes after that .... then you'd just go to "2.x". Make sense? But, I am aware that others might think differently, and I can see pros and cons with both methods.

With the long history of GEF and the stability its API has had in the last ten years, flipping the bit from „0“ to „1“ for GEF4 will be a „statement" to our community. That’s the reason why my team wants to postpone the decision until we are sure that this stability is reached. Technically speaking, I would rather sooner than later switch to 1.0.0 because that would mean we could properly employ API tooling and rely on OSGi versions to indicate compatibility.

Thanks again, good luck!

Thanks!

From:        Alexander Nyßen <nyssen@xxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        08/23/2015 07:07 AM
Subject:        [cross-project-issues-dev] GEF participations in Neon
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

---

GEF will participate in Neon and will contribute either a minor (3.11.0) or a major (4.0.0) release: https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon. The decision depends on whether GEF4 is to be graduated to 1.0.0 (or a minor 0.3.0 revision is published instead). The team has decided to leave this decision open up to M5. We will start with contributing GEF4 in version 0.3.0 to M2.

The offset will stay at +1.

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" deleted by David M Williams/Raleigh/IBM] _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
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