> The 3.9.0M1 being included in SR1 seems to be an unchanged 3.8.0 with respect > to bundles
I meant 3.8.1 of course. 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 -- 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
