Ok, we will go with „Plan B“ then (I adjusted the Mars.1 simrel aggregator to include GEF4 0.1.0 from the original GEF 3.10.0 (Mars) release). Actually all of the GEF4 API is yet provisional (and its properly marked as such, as all packages are exported with x-internal or x-friends). And while all breaking changes are also probably documented (consider the New and Noteworthy for a complete list), there is no need to risk somebody gets broken via the simrel update site. We will thus contribute GEF4 0.2.0 on our local releases site only (I will announce it on gef-dev after the review documentation has been approved, and have already updated our release plan to indicate it in the deliverables section).
PMC, please approve our 3.10.1 release review documentation based on that premises.
Kind Regards Alexander
(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/IBMTo:
Alexander Nyßen <nyssen@xxxxxxxxx>,
Date:
08/14/2015 04:32 PMSubject:
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@IBMUSDate:
08/14/2015 03:52 PMSubject:
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]
-- 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
|
