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