----- Forwarded by David
M Williams/Raleigh/IBM on 08/14/2015 04:57 PM -----
David M Williams/Raleigh/IBM To:
Alexander Nyßen <nyssen@xxxxxxxxx>,
08/14/2015 04:32 PM Subject:
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.
Alexander Nyßen <nyssen@xxxxxxxxx> To:
Tools PMC mailing list
David M Williams/Raleigh/IBM@IBMUS Date:
08/14/2015 03:52 PM Subject:
review documentation for GEF 3.10.1 (Mars SR1) release
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
deleted by David M Williams/Raleigh/IBM] -- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer