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 >> >> >
