Thanks Alexander. I think you are "leading
the way" in exposing issues with "frequent releases", API
evolution, and the problems with "provisional APIs".
I'll mark as "approved", but
sounds like your 3.10.1 release is now "just service". As such,
it does not really need a formal review process or approval.
Not sure if your Plan B is meant to
include a formal release of "GEF4 0.2.0" as part of the "3.10.1"
release? (And, just not put GEF4 0.2.0 in Sim. Release repo?)
Now, for the next level of complication
... Things like features and products (and update sites?) are supposed
to have a version increment that follows the largest _increment_ of what
it contains -- not just the "largest version" of what it contains. I am not
sure you do have just one feature that represents "all of GEF"
... but, if you did, seems like it should be 3.11.0 (i.e. incremented in
minor field) if it "contains" GEF4 0.2.0.
I'd suggest if you don't have such a
thing, you may want to start having one ... even if was "mere packaging"
for an update site and/or the update site's version. That might help the
community (and us :) to keep things straight?
I think another complication you are
exposing here is the idea that "a project has one release, for everything".
I do think that's implied in some of the EDP documents, but does not make
much sense, seeing what you are going through. I would seem quite natural
for you to have a release (stream) of GEF 3.10.x and another for GEF4 0.x
stream? If you think that's true, perhaps we should clarify or improve
EDP? Though, I could also see other ways of handling it, if you had a 3.10.x
stream and an 3.11.x stream. One of those "high level" streams
would contain "unchanged" versions of the other "sub streams"
... and, presumably, they would "synch up" once per year? And,
presumably then have a 3.11.x and 3.12.x stream to begin the next round
of evolution? Sorry to be "jabbering" ... but, it is early on
Thanks for your care -- it is definitely
needed and appreciated for a "core foundation" library such as
Let us know how we can help make things
Alexander Nyßen <nyssen@xxxxxxxxx> To:
David M Williams/Raleigh/IBM@IBMUS,
Tools PMC mailing list
08/15/2015 06:02 AM Subject:
of review documentation for GEF 3.10.1 (Mars SR1) release
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.
----- Forwarded by David M Williams/Raleigh/IBM on 08/14/2015 04:57 PM
M Williams/Raleigh/IBM To: Alexander
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
Thanks, keep us posted.
Nyßen <nyssen@xxxxxxxxx> To: Tools
PMC mailing list <tools-pmc@xxxxxxxxxxx>,
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
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
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