felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Handling of provisional OSGi API
Date Sat, 18 Sep 2010 17:34:25 GMT

While I understand (and certainly don't underestimate the consequences
of) the drawbacks of option (1) I still think it is the better option.

At the time the OSGi releases the official API, we can still keep our
internal API for certain period of time thus supporting both API, if we
so wish.


Am 17.09.2010 18:35, schrieb Richard S. Hall:
>  For a long time, we've played a little fast and loose with our handling
> of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo 0.6.0
> releases, we've started to evolve a policy on how to handle this, but
> nothing has been decided concretely. This is problematic since it leads
> different people to different decisions. Thus, its about time we defined
> our policy on this.
> So, what's the issue?
> Provisional OSGi API is not official. Further, provisional package
> content is evolving and these changes are not always made readily
> available by the OSGi Alliance. Even though some of us are members of
> the OSGi Alliance, we are not necessarily at liberty to disclose changes
> to internal RFCs.
> So, what can we do about it?
> I see two potential [reasonable] policies from which we could choose:
>   1. Always use the org.apache.felix package namespace for provisional
>      OSGi API until the spec goes final.
>   2. Use the org.osgi package namespace while the provisional API is in
>      development, but only expose what has been publicly made available
>      by the OSGi Alliance.
> Both approaches have their drawbacks.
> The benefit of (1) is that the legal/IP/etiquette issues and/or concerns
> are reduced to those associated with normal open source development. For
> completely new development, like Gogo, this would all happen in non-OSGi
> packages, while changes to existing packages would need to be done in
> subclasses in non-OSGi packages. One downside of (1) is that it will
> always result in a package name change at the end that will break
> existing clients. For this reason, such experimental packages should be
> exported with mandatory attributes to warn potential clients.
> The benefit of (2) is that the package namespace is more consistent. The
> downside of (2) is that it is a IP/legal/etiquette gray area as to
> whether or not we can do official releases of subprojects containing
> provisional OSGi API. Even if we do not modify the API, it still is
> potentially confusing to our users who are getting an "official" release
> from us of a subproject containing these "unofficial" bytes. At a
> minimum we would also need to use deprecated tags and/or mandatory
> attributes to warn people. Even then, it still raises issues since we
> aren't at liberty to evolve the packages freely to include OSGi
> internal, non-public RFC updates, nor extensions for potential feedback
> into the RFC. In those cases, we would still need to resort to putting
> stuff in org.apache.felix packages and renaming later once the changes
> become public, which would also be problematic for clients. Also, you
> have to consider the case where the RFC is abandoned, in which case if
> we still find it useful, we'll be forced to change our package names.
> From my point of view, approach (1) might not be awesome, but it results
> in a simpler process than (2). So, I'd recommend (1). If the majority
> prefers (2), then we can do that (although I think we'll have to run the
> decision by the board first).
> Thoughts?
> -> richard

View raw message