| Re: [cross-project-issues-dev] GEF Version Numbers |
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: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer 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.
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: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ian Bull 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 <alexander.nyssen@xxxxxxxxx> wrote:
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
-- |