Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMit8SpczSoWHf-cTSxnWg4M+k_pMmkgxkySKYH0Yo0ohOk6ww@mail.gmail.com>
References: <CAMit8SrQoAax20d4xQ4rj6AZW9C7nLbZ5H7Kd=riEktZSyd8Qw@mail.gmail.com>
 <ab44ffd7-3d83-755b-fd55-2c0154df03bc@ungoverned.org> <CAMit8SoG2Ouq-D65+02aTocJjr=pqdgBQ6S2=U0McNwCW8OWNQ@mail.gmail.com>
 <AFAC40EB-65AE-4FC6-A180-891D5F755BB4@adobe.com> <1c5794b9-1452-4bdb-25d4-7e2a1d0dbc64@ungoverned.org>
 <CAMit8SoFYwYgB3hGacg4cdts75RmCNx22bornEtUK-KpVi9H-g@mail.gmail.com>
 <d3750155-235b-7d0b-9522-007e15766460@ungoverned.org> <CACmMR0NoquSP4_nk3BnfyiZJDSZoVjPDDyaJMJoSsjUkSLJvtw@mail.gmail.com>
 <CAMit8SpczSoWHf-cTSxnWg4M+k_pMmkgxkySKYH0Yo0ohOk6ww@mail.gmail.com>
From: Thomas Watson <tjwats@gmail.com>
Date: Tue, 3 Jan 2017 15:17:34 -0600
Message-ID: <CACmMR0Pi7u0Niy04=biN2tUvhxx3A9M7fQtt=xx-oDMfOxWn1w@mail.gmail.com>
Subject: Re: Proposal for slight amendment to Felix provisional OSGi API policy
To: dev@felix.apache.org
Content-Type: multipart/alternative; boundary=001a1147b5006719e9054537322d
archived-at: Tue, 03 Jan 2017 21:17:51 -0000

--001a1147b5006719e9054537322d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.co=
m
> 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 version=
s
> <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 =E2=80=9Eprovisional=E2=80=9C with value =E2=
=80=9Efelix=E2=80=9C. 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 generat=
e
> a
> > >>>> version-less import, which essentially means =E2=80=9Eany version=
=E2=80=9C, which
> > >>>> really is
> > >>>> bad. All exports always should have an export version.
> > >>>>
> > >>>> Now, to Richard=E2=80=99s 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 elsewher=
e.
> > >>>>
> > >>>> WDYT ?
> > >>>>
> > >>>> Yes, this is exactly the point that made us arrive at our policy i=
n
> > the
> > >>> first place. We do not have permission or release provision API fro=
m
> > the
> > >>> OSGi Alliance. If I recall correctly, we are only granted permissio=
ns
> > 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 g=
et
> > >>> into
> > >>> situations where the OSGi Alliance kills something (e.g., Gogo) tha=
t
> 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 thin=
k
> 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 statemen=
t
> > 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 abou=
t
> > > 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 cu=
t
> 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 t=
o
> be
> > > explicit change of terms.
> > >
> > > It's been a while, so who knows, maybe the terms have been loosened u=
p
> 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
> > >>
> > >>
> > >
> >
>

--001a1147b5006719e9054537322d--