User-agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
Thanks for all your hard work keeping the release train on track!
I'm sure many people, not just I, appreciate it a great deal!!
On 23/09/2011 9:38 AM, Kenn Hussey wrote:
Actually, if we post an M2a build for EMF, it should
be possible for folks to build against it even if the platform
(4.2) doesn't respin - by referencing the EMF milestone repository
you should be able to pick up the right version depending on
whether you are building against Eclipse 3.8 or 4.2.
No, this definitely isn't a good thing.
We must tolerate and even support 3.x so
we must build and test against that. If
we don't do that, we've basically made
this decision for a large fraction
(majority) of the release train which I
don't feel is appropriate. The platform
team has made it clear that 4.x must be
compatible with 3.x so anything in EMF we
discover (or downstream clients discover)
doesn't work with 4.x will be something
the e4 team needs to address. We need to
change this as soon as possible...
Hopefully we'll be able to upgrade our
builds so that the build is done and
tested against 3.x and then retested
against 4.x, but that's a longer term
On 23/09/2011 9:05 AM, Kenn Hussey
The dependency versions for EMF
are determined at build time based
on the target it is built against.
Since we built EMF 2.8 M2 against
Eclipse 4.2 (given that the Juno
train is being based on 4.x), the
dependency versions are based on
4.2... We could switch back to
building against 3.x but then we'd
have less confidence that things
work properly in 4.x...
switching the EMF
version we use from
2.7 to 2.8 I noticed a
the EMF 2.8 version
has a plugin
problem appears when
we try to build
against the Eclipse
3.8 milestones update
site for M2: there is
in version 3.8.0
available which causes
an unresolved plugin
error. The Eclipse 4.2
milestones update site
for M2 contains two
(versions 3.8.0 and
thoughts? It appears
at least strange to
me. What is the