Re: [equinox-dev] R4 / R5

[Thomas Watson <tjwatson@xxxxxxxxxx>]

equinox-dev-bounces@xxxxxxxxxxx wrote on 09/06/2006
09:52:27 AM:

> 
> Now that the work on the OSGi R5 spec has started and that we are
> actively involved in it by prototyping some ideas, I would like to
> understand what we should be doing wrt our codebase. More 
> specifically here are the question that I have in mind with my 
> answers for them. 
> 
> 1) What do we ship in eclipse 3.3? Do we believe that R5 will be 
> close enough to completion so that we ship 3.3 on an R5 preview 
> (like we have done with for eclipse 3.1 and R4.0), or do we maintain
> R4 in 3.3 until R5 is completly released? 
>         (no answer) 

R5 is a long ways out and will not be close to being
ready in time for 
a 3.3 release.  OSGi is focusing on an R4.1 release
now which I think 
should be close to being ready/final by the 3.3 release
(BJ is this 
true?).  The R4.1 changes should be isolated
and we should be able 
to contain the changes in 3.3.

> 
> 2) Where in CVS should the development / exploration of R5 feature
be made? 
>         For now I propose to explore things in
a branch to avoid 
> unncessary perturbations. As features stabilize, they can be moved
> to HEAD if we decide to ship R5 in 3.3. 
> 

Branches are fine, but we should move to HEAD as early
as possible.  Again 
I don't anticipate any major R5 features to be far
enough along in the 
spec process for us to consider in the 3.3 release.
 But we need to have 
R4.1 features in the I-Builds as early as possible
to get proper testing 
done in the 3.3 cycle.  This is important to
other teams looking at 
OSGi, for example the spring-osgi work.

> 3) Should we maintain a R4 branch? 
>         Yes in order to produce equinox build
of R4 and to not force
> everybody in the community to use R5 if they don't need it. 
> 

Why is this different than a 3.2.x maintainance branch?
 Are you 
suggesting two different versions of equinox for 3.3,
one that 
supports R4.0 and one that supports R4.1?  I
think we need to 
be able to move forward in HEAD and do our maintainance
in the 
existing maintanance branches for 3.2.x, 3.1.x etc..

Tom