felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Framework roadmap
Date Thu, 10 Mar 2011 20:01:03 GMT
A heads up...

I've committed a pretty substantial patch to the framework resolver, 
which furthers the goal of eventually making it a separate 
module/subproject. Previously, the resolver did not actually handle 
fragments or singleton bundles and instead left this up to the user of 
the resolver. The new resolver handles these aspects of the OSGi 
resolver algorithm internally, thus greatly simplifying the task of the 

At this point, I am planning on doing a framework 3.2.0 release to get 
this out in the wild as soon as possible. I'll am currently looking into 
picking off a few of the "low-hanging fruit" issues to include in the 
release. This release will still not see the resolver become its own 
module, however, since the outward facing API is likely to change 
substantially over the next couple months as a result of the new R4.3 API.

Once 3.2.0 is out the door, I am hoping to start to focus my energy on 
implementing R4.3. This is likely to have substantial impact on the 
framework implementation, because it introduces new concepts (like 
revisions and wirings) that more closely model existing implementation 
details. I think the best plan is to try to adopt this new API as our 
implementation API directly (where possible) rather than creating 
facades and wrappers for our existing abstractions. That'll be my 
initial goal, we'll see if it is possible.

Assuming it is, it'll mean that the next major release of the framework 
will be a little ways off into the future and quite a bit different 
internally. This likely means that once I start to commit these changes 
we'll probably have to do future 3.2.x bug fix releases from a branches 
off of the 3.2.x release tags, rather than trunk. I suppose the other 
option is to branch 4.0 and keep trunk as 3.2.x and replace it with 4.0 
once it is done.

For me, I prefer to keep the main development in trunk, but I could be 
convinced otherwise if people objected.

-> richard

View raw message