If GEF is (or has) released a feature with the version 3.9 and there is a new GEF release that contains additional API, then it should (must?) increment it's minor version to 3.10. If there is no new API between what's been released and Kepler, then I supposed that keeping 3.9 is ok, but really a increment in the service number should be included. (3.9.1?).
I'm not sure how this affects all future releases? It means Juno SR0: GEF 3.8.0 Juno SR1: GEF 3.9.0 Juno SR1: GEF 3.9.0 (different qualifier) Kepler SR0: GEF 3.10.0 Kepler SR1: GEF 3.10.1 It's a little odd, but it allows adopters to target their dependencies. Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard time specifying if they want GEF Juno or GEF Kepler. Cheers, Ian On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen <[email protected] > wrote: > > The GEF and M2E bugs were also discussed. The M2E bug was perceived as a > bug that could be addressed by the project's own update repo and "hot fix" > process. The GEF issue is more complicated, can not be fixed by their own > update site, exactly, since part of the damage already exists in SR1. We > recommend to them to make their Kepler version be GEF 3.10, since various > Juno versions will have some 3.9 and some 3.8; the differences in code are > relatively minor, as I understand it, with the version change being the > worst, and some adopters will have to work-around that, but it is feasible > to live with it. > > > Hmm, I am not sure whether I like that "recommendation". GEF's release > policy has always been easily traceable for all our clients, and with > respect to our own update sites there is indeed no problem involved: we > have released 3.8.0 and 3.8.1 on the GEF's releases update site properly > and we intended do the same with 3.8.2 (which is the intended release for > Juno SR2). Because of a missing upper version limit in the gef.b3aggrcon > file it happened that GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 > (which - as far as I remember - still contained the 3.8.1 bundles, only the > feature versions were incremented at that time) and accordingly 3.9.0 M5 is > now used instead of 3.8.2 in the SR2 (which actually contains 3.9.0 > bundles). Leaving 3.9.0M5 within the SR2 release repo is one thing (I can > understand the councils decision, even if I would have liked it to be > otherwise), but I don't like that this is going to affect all our future > releases as well. Having said so, I would propose that with Kepler we will > continue exactly as planned, i.e. ship our intended 3.9.0 release. All our > bundles and features are properly equipped with qualifiers, so there should > be no problem if the 3.9.0M5 in Juno SR2 is succeeded by the actual 3.9.0 > release in Kepler. This way, the Juno SR1 and SR2 aggregator repos would be > the only places that reflect the above mentioned inconsistency and from > Kepler on, everything would be fine again (and we will not have to explain, > where we lost our 3.9.0 release). Concerning the GEF releases site, I would > like to go for the intended 3.8.2 release there, so clients can consume it > from there if they want to, while the 3.9.0M5 is also available from our > milestones site. > > Cheers > Alexander > > Dr. Alexander Nyßen > Dipl.-Inform. > Software-Engineer > > Telefon: +49 (0) 231 / 98 60-210 > 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: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus > > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
