On 9/20/10 11:21, Derek Baum wrote:
I also favor #1.
When we apply this to gogo, it will mean removing the draft RFC-147 API from
the org.osgi.service.command namespace and moving it to a felix namespace.
We actually already did this for the gogo-0.6 release, but then reverted the
change in the trunk, as it broke many command providers who imported
org.osgi.service.command. Back then we didn't have a policy for supporting
draft OSGi APIs, but now it seems like we've agreed on #1. Do we need a
vote?
It sounds like we have consensus, so we can probably just move forward.
-> richard
Derek
On 19 September 2010 17:27, Richard S. Hall<[email protected]> wrote:
On 9/18/10 10:34, Felix Meschberger wrote:
Hi,
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.
From my point of view we should just export the packages with mandatory
attributes and make it clear they will change when the API goes final. For
framework, I wouldn't plan to provide any ongoing support for provisional
API. However, I don't think we need to mandate a global Felix policy for
this and subprojects can choose to support two APIs if they want.
-> richard
Regards
Felix
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
