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

Reply via email to