Hi David, please find my comments below. > Am 24.08.2015 um 14:49 schrieb David M Williams <[email protected]>: > > Thanks Alexander, for letting us know. I myself won't object to your "M5" > timing, and since is for GEF4 (not GEF in general) I suspect all is fine, > either way. > > But, I wanted to remind you, and the whole "extended team", that it is best > to settle these issues as soon as possible. The reason is that some (many?) > projects like (or need) to support running on more than one version of > Eclipse (such as current -1, or a few even do current -2). For those > projects, if they used GEF 4, they *might* need to do something special to > handle such a change ... so ... for them, the earlier they know, the better > they can react OR, perhaps, even change their plans (and then they have to > let their adopters know too, etc.)
As stated, we want to take that decision with M5 at the latest, which is well before API and feature freeze. There are a couple of themes we want to address (see https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon/plan <https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon/plan>), and the decision will be mostly based on the progress and results achieved there. > > Would your change from "0" to "1" reflect "breaking API" (such as, would you > be renaming packages from "provisional" or "internal" to be true "API > packages"? Or, does the versioning just reflect whether or not you've > graduated? GEF4 is not in incubating state, its not even a sub-project of GEF. Technically speaking, all GEF4 components are pure provisional API of the GEF project (i.e. all exported GEF4 packages are currently guarded by x-internals or x-friends). We have decided to use the 0.x versions for the GEF4 bundles and features only to indicate that there is no public API yet (and that breaking changes of the provisional API might occur between minor revisions, which already happened between 0.1.0 and 0.2.0). For Neon, we will break (provisional) API in either case, even if we decide to only publish 0.3.0. The step from „0“ to „1“ would basically mean that we decide to turn some or all of our provisional API into public API (i.e. remove the x-internals). > > Again, for your case, I doubt it would matter (too much :), but I thought > best to explicitly document how "major" increases can impact others in ways > that some might not be aware of. Not everyone is concerned with "just the > current release". > > I personally think "graduation" is not too related to the "state of your > code", but more to your ability to demonstrate you are a self running > project, with some adopters, involved with community, etc. So, for example, > even if you publish "1.x" with what ever you have, if you decide to make > breaking API changes after that .... then you'd just go to "2.x". Make sense? > But, I am aware that others might think differently, and I can see pros and > cons with both methods. With the long history of GEF and the stability its API has had in the last ten years, flipping the bit from „0“ to „1“ for GEF4 will be a „statement" to our community. That’s the reason why my team wants to postpone the decision until we are sure that this stability is reached. Technically speaking, I would rather sooner than later switch to 1.0.0 because that would mean we could properly employ API tooling and rely on OSGi versions to indicate compatibility. > > Thanks again, good luck! Thanks! > > > > > > > > From: Alexander Nyßen <[email protected]> > To: Cross project issues <[email protected]>, > Date: 08/23/2015 07:07 AM > Subject: [cross-project-issues-dev] GEF participations in Neon > Sent by: [email protected] > > > > GEF will participate in Neon and will contribute either a minor (3.11.0) or a > major (4.0.0) release: > https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon > <https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon>. > The decision depends on whether GEF4 is to be graduated to 1.0.0 (or a minor > 0.3.0 revision is published instead). The team has decided to leave this > decision open up to M5. We will start with contributing GEF4 in version 0.3.0 > to M2. > > The offset will stay at +1. > > Cheers > Alexander > -- > 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 <http://www.itemis.de/> > [email protected] <mailto:[email protected]> > > 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] > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- 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 [email protected] 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
