My preference would be to do new osgi R-Next work in a dedicated feature branch instead of directly in trunk. That way trunk remains releasable at all times. But if we want to instead branch each project when its trunk version becomes unreleasable then I guess that is fine, but it does seem confusing.
If that is what felix dev has agreed to then I do request a branch for scr to release some fixes for the R6 scr implementation. I'm have a few fixes that I need to get released very soon in order to allow the felix scr implementation to be used as the DS implementation in Eclipse. Tom On Wed, Jan 4, 2017 at 1:56 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > Thomas Watson wrote > > This has come to my attention because I am working on some fixes in the > SCR > > implementation. I noticed the latest SCR in trunk now depends on > > org.apache.felix.configadmin 1.9.0-SNAPSHOT. And I think > > org.apache.felix.configadmin 1.9.0 is being used to implement OSGi R7. > So > > now we have OSGi R7 API updates in trunk for existing OSGi packages. If > I > > understand correctly that means trunk is no longer in a state where we > can > > release SCR or configadmin out of. Instead we have to create a branch to > > get new releases of these bundles until a time when OSGi R7 is finalized > > and released. That seems like a bad state to be in. > > > > We already have the branch for config admin and if we think that we need > another R6 based release of SCR we can create the branch on demand like > we did with config admin. > I started with these two projects in a branch and at one point we have > to merge the branch into trunk. I thought that now is the time as I > didn't expect another release before R7 will be out. Might be wrong... > In any case, creating that branch is easy. Just shout and it will be done. > > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
