The 3.9.0M1 being included in SR1 seems to be an unchanged 3.8.0 with respect to bundles (I assume the branches had not diverged at this point), and only the feature versions increased to 3.9.0 (I will cross-check that again, but the bundles should just have different qualifiers w.r.t. the 3.8.1 versions). 3.9.0M5 actually does not contain many changes either. I intended to address a couple of issues for M6, but I did not have the chance to contribute much to it up to now (Matthias and I have spent work on GEF4), so there is actually just three changes involved:
1) https://bugs.eclipse.org/bugs/show_bug.cgi?id=388697 Changed the visibility of a member 2) https://bugs.eclipse.org/bugs/show_bug.cgi?id=394137 Introduced a new doc bundle for Zest 3) https://bugs.eclipse.org/bugs/show_bug.cgi?id=395872 Fixed the ICU dependencies Fear about using untested bundles therefore is rather baseless. However, it would be nice if we can get this right in the final SR2 repo, as this will remain in place. Is there no chance we can remove GEF 3.9.0M1 from the composite repo and include the intended 3.8.2 now into a respinned SR2? The 3.8.1 has been released on our project releases site, so clients could still consume it from there. Of course this would mean a one-time adoption, but after that things would be ok. Cheers Alexander Am 23.02.2013 um 08:06 schrieb Ed Willink <[email protected]>: > Hi > > Surely we must lose GEF 3.9.0 M5, so we must respin to pick up 3.8.2 that > must be reversioned as 3.9.0 to succeed 3.9.0M1 in SR1? Then 3.10.0 for > Kepler. > > [When this is all over, can we have a clearer policy on maintenance releases > being maintenance releases, with some aggrcon tooling that diagnoses > maintenance version consistency? Seems like this could have avoided both the > EGIT and GEF problems.] > > Regards > > Ed Willink > > On 22/02/2013 23:41, Konstantin Komissarchik wrote: >> Alexander Nyßen wrote: >> >> > 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) >> >> [snip] >> >> > 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains >> > 3.9.0 bundles) >> >> The situation in SR2 is far more severe than what happened in SR1. If SR2 >> respin is done to pick up the correct GEF 3.8.2 release, then users with GEF >> installed from SR1 repo will not be able to upgrade GEF, but at least no one >> will be running with pre-release code. Pick your poison. >> >> - Konstantin >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Doug >> Schaefer >> Sent: Friday, February 22, 2013 3:32 PM >> To: [email protected]; 'Cross project issues' >> Subject: Re: [cross-project-issues-dev] GEF Version Numbers >> >> If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that >> seams, that ship already sailed. >> Sent from my BlackBerry 10 smartphone. >> >> From: Konstantin Komissarchik >> Sent: Friday, February 22, 2013 5:55 PM >> To: 'Cross project issues' >> Reply To: Cross project issues >> Subject: Re: [cross-project-issues-dev] GEF Version Numbers >> >> Frankly it’s rather scary that SR2 will run on a milestone build of GEF. How >> much testing was there on this milestone to assure fitness for SR2? >> >> I know that I, along with others how build upon GEF, would rest easier if >> the GEF issue was also resolved in the respin. This is the last Juno service >> release. Let’s get this right, even if it takes a bit longer. >> >> - Konstantin >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Ian Bull >> Sent: Friday, February 22, 2013 2:50 PM >> To: Cross project issues >> Subject: [cross-project-issues-dev] GEF Version Numbers >> >> 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 >> >> >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.2899 / Virus Database: 2639/6121 - Release Date: 02/21/13 >> > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- 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
