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.
Tom On Tue, Jan 3, 2017 at 1:25 PM, David Bosschaert <david.bosscha...@gmail.com > wrote: > Hi Tom, > > My proposal here only applies to implementations of entirely new specs. > Updates on existing specs are not covered, hence the point around versions > <1. > > I completely agree that updates to existing specs should be done on a > branch to keep trunk releasable. > > Cheers, > > David > > On 3 January 2017 at 19:22, Thomas Watson <tjw...@gmail.com> wrote: > > > Why do OSGi R-next work directly in trunk where I would expect releases > > could be done at any time. It seems to me that trunk should remain > > 'releasable'. It would be much more simple to do OSGi R-next work in a > > dedicated branch where you have the freedom to put interim OSGi APIs > > assuming we would never produce a release from the osgi-r-next branch. > > Instead, stuff from the osgi-r-next branch would be selectively merged > into > > trunk when they are ready AND the OSGi specification has gone final. > > > > Also, I don't get this <1 version proposal. That may seem fine for new > API > > packages, but what about changes to existing OSGi API packages that are > > happening in R7? Surely these cannot go to <1. Perhaps I missed what > > happens here from the original proposal. > > > > Tom > > > > On Tue, Jan 3, 2017 at 11:21 AM, Richard S. Hall <he...@ungoverned.org> > > wrote: > > > > > > > > On 1/3/17 11:59 , David Bosschaert wrote: > > > > > >> Hi Felix and Richard, > > >> > > >> On 3 January 2017 at 16:40, Richard S. Hall <he...@ungoverned.org> > > wrote: > > >> > > >> On 1/3/17 11:21 , Felix Meschberger wrote: > > >>> > > >>> Hi > > >>>> > > >>>> Upfront I like the amended proposal of using a version < 1 and a > > >>>> mandatory attribute „provisional“ with value „felix“. As Neil said, > > BND > > >>>> will solve this for imports be it the bndtools or the maven bundle > > >>>> plugin. > > >>>> > > >>>> Not declaring a version and thus using 0.0.0 will have BND generate > a > > >>>> version-less import, which essentially means „any version“, which > > >>>> really is > > >>>> bad. All exports always should have an export version. > > >>>> > > >>>> Now, to Richard’s point: I think this is very valid and we better > take > > >>>> good care here. If we include OSGi API in our releases it is a > > >>>> re-release > > >>>> of AL2 licensed bits. Key is re-release. If we release provisional > > OSGi > > >>>> API > > >>>> in the OSGi name space which has not been released by OSGi yet, we > are > > >>>> essentially first-party releasing it. > > >>>> > > >>>> So before we go this route, I would like to have the OSGi Alliance > > make > > >>>> a > > >>>> statement on this topic. In fact, it would make sense for the > alliance > > >>>> to > > >>>> make an official statement not only to the benefit of the Felix > > project > > >>>> but > > >>>> to the benefit of all OSGi-related projects at Apache and elsewhere. > > >>>> > > >>>> WDYT ? > > >>>> > > >>>> Yes, this is exactly the point that made us arrive at our policy in > > the > > >>> first place. We do not have permission or release provision API from > > the > > >>> OSGi Alliance. If I recall correctly, we are only granted permissions > > to > > >>> provide _compliant_ implementations of released API. > > >>> > > >>> We have no way to achieve that requirement, which puts us in a gray > > area. > > >>> Thus, we arrived at 1) only doing snapshots or 2) changing the > package > > >>> name. > > >>> > > >>> As Felix M. suggests, one way to remedy this is to get additional > > >>> explicit > > >>> permission from the OSGI Alliance that we are allowed to create > > official > > >>> releases containing provisional API. However, this means we could get > > >>> into > > >>> situations where the OSGi Alliance kills something (e.g., Gogo) that > we > > >>> want to continue and we have created legacy in the OSGi package > > >>> namespace. > > >>> > > >>> It sucks, but that is the reality of the situation. > > >>> > > >>> -> richard > > >>> > > >>> > > >>> The OSGi Alliance has never released API with version <1 and I think > it > > >> never will. This means that any API with version <1 that would be in > > Felix > > >> provisional release would never clash with a released OSGi API. > > >> > > > > > > That's irrelevant. The issue at hand is the the org.osgi package > > namespace. > > > > > > AFAIK OSGi has never made a statement about the Felix release policy > but > > I > > >> guess it might be possible to try and get a statement from OSGi that > it > > >> will never release versions <1 and that implementation projects are > > >> allowed > > >> to use versions 0.x during the initial creation of an implementation > of > > a > > >> new, previously unreleased spec. > > >> > > >> I can take this up to the OSGi folks and see if I can get a statement > > like > > >> that... > > >> > > > > > > I'm not sure why you are fixated on the version, since that seems > > > immaterial to me. The OSGi Alliance has never made any statement about > > > Felix release policy, but they did have general words in place saying > > what > > > the requirements were for being allowed to use their IP. > > > > > > I'm fairly certain that the OSGi Alliance is not interested in losing > > > their tight control over the org.osgi package namespace (nor should > they > > > be). Further, some statement saying "yeah, it's ok" doesn't really cut > it > > > if there still exists wording on requirements on who/how we can use > their > > > IP, since they could change their mind and then what? It would need to > be > > > explicit change of terms. > > > > > > It's been a while, so who knows, maybe the terms have been loosened up > at > > > this point and it would be possible to do it differently, but it wasn't > > > possible previously without entering a gray area with IP which is one > of > > > the main things that the Apache release process tries to eliminate > > > confusion over. > > > > > > -> richard > > > > > > > > >> Cheers, > > >> > > >> David > > >> > > >> > > > > > >
