| Thanks David,
I appreciate your detailed answer and have added some detailed comments below.
+1
Thanks Alexander. I think you are "leading
the way" in exposing issues with "frequent releases", API
evolution, and the problems with "provisional APIs".
Well, I fear somebody has to :-).
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?)
The plan is indeed to include a formal release of GEF4 0.2.0 that is promoted to our project releases site only. As such, it is more than „just service“ and the formal review process seems to be required.
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?
An umbrella feature for GEF and GEF4 IMHO does not make sense from an organizational as well as technical point of view. Both streams are developed completely independent of each other, each with its own git repository and each with its own update-site (there are also no dependencies between the code bases). The only thing they share is the release date. There already is an umbrella feature for Draw2d, GEF (MVC), and Zest (namely GEF-ALL, which is accordingly provided in version 3.10.1), but I already find that misleading, as it contains Zest 1.x and the Zest version is never directly visible. GEF4 actually does not provide an umbrella feature because of this, it was designed to consist of nine individual components that are only loosely coupled.
Because of that I would rather not tend to name the overall release GEF 3.11.0 (Mars.1) now, because that would IMHO be even more disturbing to our community. The release would not contain a single 3.11.0 feature, as the highest included feature would be GEF-ALL 3.10.1. And it would not get better after Mars.1 either, if we decide not to release GEF4 1.0.0 with Neon (but only 0.3.0), because the GEF 3.12.0 (Neon) would then contain Draw2d/GEF (MVC) 3.11.0, Zest 1.7.0, and GEF4 0.3.0, so no 3.12.0 feature would be included either). As we want to ultimately replace GEF 3.x with GEF4, I would rather tend to name the release logically after the respective „leading“ feature, i.e. use the GEF-ALL 3.x version until we release GEF4 1.0.0 as part of a GEF 4.0.0 overall release, and from then on use GEF4 as „leading“ (because GEF 3.x is in maintenance mode only, so there will be no further major version increment resulting from it). I would actually like to plan a 4.0.0 release already for Neon, but we will have to discuss that internally first, a decision about it is not made yet.
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
Saturday. :)
I agree that the „one project has one release, for everything“ idea is bringing trouble. Nevertheless, I see the problem somewhere else: it would IMHO be fine to have a single release date, where different features of a project are simultaneously released (the simrel approach is nothing else). The real problem for me is that a release seems to impose that a single umbrella feature has to be there. The need for a single release version already implies this. If I could label the release as „GEF 3.10.1 / Zest 1.6.1 / GEF4 0.2.0“ it would be quite clear for the community what to expect. And even if I simply called it "GEF Mars.1“ it would IMHO be more transparent, because one would have to look into the release plan to see what is included in detail and would not get mislead by a single release version. Why not allow symbolic release names for projects and instead enforce that the plan/review meta-data contains detailed information about the delivered features (I already tried to apply this to GEF, as our release names contain the logical simrel release name as a suffix, and as the deliverables are detailed out on the level of individual features/bundles/fragments within https://projects.eclipse.org/projects/tools.gef/releases/3.10.1-mars-sr1/plan)?
Thanks for your care -- it is definitely
needed and appreciated for a "core foundation" library such as
GEF,
Let us know how we can help make things
easier,
Thanks for your support. I hope I could make a few points clearer. Maybe my last argument about symbolic release names and more formal deliverables data within plan/review documentation is worth to be discussed further.
Kind Regards, Alexander From:
Alexander Nyßen <nyssen@xxxxxxxxx>To:
David M Williams/Raleigh/IBM@IBMUS,
Cc:
Tools PMC mailing list
<tools-pmc@xxxxxxxxxxx>Date:
08/15/2015 06:02 AMSubject:
Re: Approval
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.Kind RegardsAlexanderAm 14.08.2015 um 22:58 schrieb David M Williams <david_williams@xxxxxxxxxx>:(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]
--
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
|
