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
