My understanding was that 3.8 would also be part of Juno, the IDE
releases will just be based on 4.2. If indeed 3.8 is going to be
such a crippled release, why do it at all. Surely they will have to
have 3.8 repositories to support the downstream consumers that
cannot migrate to 4.2. Builds for 3.8 are still available as of M3
, so I would assume there is still some support for building
against that platform.|
Also, I don't see how we can release RAP 1.5 based on 4.2 as that
would break API versioning rules. If we must use 4.2, then it will
have to be called RAP 2.0.
My vote is that we try to work with the appropriate projects to
ensure that we can deliver RAP 1.5 based on 3.8 as part of the Juno
release. If we have the resources, then we could look at also
starting work on RAP 2.0 to be based on the 4.2 platform.
On 11/14/2011 05:15 AM, Ralf Sternberg wrote:
it seems that we are getting into a version issue in Juno: Our
runtime is based on 3.8, but Juno contains only 4.2. Since the 4.2
bundles have started to diverge from 3.8 , we cannot bring the
basic target requirements into the Juno repository anymore, as
this provokes the usual version clashes. Moreover, if we continue
to base our runtime on 3.8, our runtime may become incompatible
with the Equinox bundles in Juno.
Since the RAP Workbench and JFace bundles are still based on 3.x,
I based the runtime on 3.8 as the natural successor of 3.7. So
what are our options?
A) Switch to 4.2 as runtime base and ensure that our
JFace/Workbench bundles remain compatible with 4.2 Equinox (not
sure if there will be any incompatible changes in Equinox).
B) Continue using 3.8 as runtime base and keep the runtime out of
the Juno repository entirely.
C) Continue using 3.8 as runtime base and keep only the basic
target requirements bundle out of the Juno repository. We'd have
to ensure that the RAP runtime works with Equinox 3.8 and 4.2.
I'd prefer to look forward and go for A). Any thoughts?
rap-dev mailing list