felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Watson <tjw...@gmail.com>
Subject Re: Proposal for slight amendment to Felix provisional OSGi API policy
Date Tue, 03 Jan 2017 21:17:34 GMT
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.bosschaert@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 <tjwats@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 <heavy@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 <heavy@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
> > >>
> > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message