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
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
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 SR1: GEF 3.9.0 (different
qualifier)
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.
On Fri, Feb 22, 2013 at 1:58 PM,
Alexander Nyßen <alexander.nyssen@xxxxxxxxx>
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.
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
alexander.nyssen@xxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
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
cross-project-issues-dev@xxxxxxxxxxx
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
|
