Well, it is not really a norm just because of the spec update. I will do it for the framework as we are going to at a minimum require java8.
For SCR, i would say it depends - if it stays backwards compatible and doesn't include any new requirements I think going with 2.2 is fine. regards, Karl On Fri, Oct 23, 2020 at 4:52 PM Thomas Watson <[email protected]> wrote: > > +1 to cutting a release off current master and working towards a release of > the OSGi R8 Framework Felix implementation. > > As I am doing the work for SCR R8 implementation I have a question about > the version of the release. I see you are going up by a major version > to 7.0.0. Is that the norm for felix release versions based on new > versions of an OSGi specification? For SCR I was planning on just moving > up minor versions to version 2.2 for the future OSGi R8 Declarative > Services implementation. The updated specification is backwards compatible > with the OSGi R7 Declarative Services. But should SCR really be moving up > to version 3.0? > > Tom > > > On Fri, Oct 23, 2020 at 9:23 AM Karl Pauls <[email protected]> wrote: > > > It has been some time since we had a framework release. Additionally, > > we have the OSGi R8 core spec being final now. > > > > As a consequence, we have some useful fixes in trunk and we have the > > „connect“ branch that passes the R8 core ct (and works a lot better > > with jpms). > > > > I think we should do a 6.0.4 release with the current trunk and then, > > subsequently, merge the connect branch into trunk and do a 7.0.0 > > release that is R8 compliant. > > > > Unless somebody thinks we absolutely have to get some other fixes in > > I’ll start with doing a resolver 2.0.1 and a framework 6.0.4 release > > soon. > > > > After that, I’m going to merge in the connect branch changes and do a > > framework 7.0.0 and framework.security 2.6.2 release which will be R8 > > core compliant. > > > > Regards, > > > > Karl > > > > -- > > Karl Pauls > > [email protected] > > -- Karl Pauls [email protected]
