Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tools-pmc] Fw: Approval of review documentation for GEF 3.10.1 (Mars SR1) release

(Sorry, guess I should have "replied all"?)

----- Forwarded by David M Williams/Raleigh/IBM on 08/14/2015 04:57 PM -----

From:        David M Williams/Raleigh/IBM
To:        Alexander Nyßen <nyssen@xxxxxxxxx>,
Date:        08/14/2015 04:32 PM
Subject:        Re: Approval of review documentation for GEF 3.10.1 (Mars SR1) release



> If this concern is shared...

Yes, I do share that concern. But, I think it also depends on your adopters, and the nature of your provisional APIs.  If you know (or, highly suspect) that some adopters, or other projects in the release train used those provisional APIs, then I think your "project site only" proposal is the best option (and, even then, you'd still have to be pretty clear about it; essentially publishing two things to your own repositories, and clearly documenting which went the Mars update release) -- and, actually, I'd even recommend simply publishing the new APIs as a Neon milestone, unless you know of someone who needs to use in a product or for the releases of a project. After all ... you've not had much time to get feedback on them, have you?

But, if your provisional APIs were new with Mars release, labeled as provisional or experimental and subject to change during update releases, then perhaps anyone who used them they would not mind adjusting? Plus, are you talking about 5 or 10 methods or classes? Or, a whole framework? Part of what you are wrestling with is not just related to provisional APIs, but also "non APIs". (I know some who say there is no such thing as a provisional API ... its either API, or its not, and I know plenty of us have used non-API from other projects.)  I know in the past, the platform has tried not to change behavior or signatures of even "internal, do-not-use methods", just to avoid the possibility that someone might be using them "illegally" and the desire not to break anyone. (In most cases that could be done ... to leave "old stuff" around, even though an API method was added for the long term, but, could not always be done, and I do not know if that is feasible for your code).

I'd say to go with your "Plan B" .... unless you can quickly get feed back from gef-dev list, and cross-project list that confirms no one is using them, or, do not mind changing their code to use the APIs.  And, again, probably wouldn't hurt to go through a few milestones with them?

Thanks, keep us posted.





From:        Alexander Nyßen <nyssen@xxxxxxxxx>
To:        Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Cc:        David M Williams/Raleigh/IBM@IBMUS
Date:        08/14/2015 03:52 PM
Subject:        Approval of review documentation for GEF 3.10.1 (Mars SR1) release




Dear PMC,

please approve the release review documentation for the GEF 3.10.1 (MARS SR1) release, which is planned to coincide with Mars.1. The review documentation can be found at http://projects.eclipse.org/projects/tools.gef/releases/3.10.1-mars-sr1/review, the approved IP log is attached.

I have to point out two things:

1) While the release has been named 3.10.1 (corresponding to the highest included feature version) to indicate that the production components Draw2d 3.10.1, GEF (MVC) 3.10.1, and Zest 1.6.1 have all been included in service revisions only, the release will include the GEF4 components in version 0.2.0 (compared to the 0.1.0 Mars version) and thus is designated as a minor release.

2) Even if the included 0.2.0 version of the GEF4 components implies compatibility towards the 0.1.0 Mars release version, as indicated in the review information and the new and noteworthy documentation (https://wiki.eclipse.org/GEF/New_and_Noteworthy/3.10.1) some GEF4 components include incompatible changes in their provisional API. As all GEF4 0.1.0 components specified their dependencies to others as [0.1.0, 0.2.0), including the 0.2.0 version in the Mars.1 simultaneous release update site would be no problem from our own project scope (nothing would break there). However, if clients have specified less strict version constraints or no version constraints at all, they might get broken if updating against the Mars.1 simultaneous release update site if we include GEF4 0.2.0 there. If this concern is shared (David, please comment), I would opt to publish GEF4 0.2.0 only on our own project releases update site and leave the GEF 0.1.0 contribution to be part of the Mars.1 simultaneous release instead (while I would of course include the 3.10.1/1.6.1 versions of Draw2d, GEF (MVC), and Zest there).

Kind Regards,
Alexander

[attachment "tools.gef-iplog.html" deleted by David M Williams/Raleigh/IBM]
--
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]


Back to the top