While overall, this is a somewhat frustrating situation ;-), I would
like to thank you Ralf for your very positive post. :-)
The main thing that concerns me is that there is no release train
for 3.8. Since projects won't be required to release a version for
3.8 this leaves it open to various problems and inconsistencies.
Being also wary of backwards compatibility in 4.2, I am cautious
about the state that the project will be in if we totally jump to
The way I see it, these somewhat surprising events will probably be
frustrating to RAP Project consumers if our next release is not
stable and/or they have to rework their code significantly.
Here are my thoughts:
1) Since 3.8 is not going to be consistent anyway, release a 1.4
maintenance build for it.
2) Change our version to 2.0, since the protocol will be fully
3) Upgrade the repository to Git.
On 11/14/2011 5: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