Guillaume and I were discussing alternatives to a mandatory attribute. An alternative idea was mark all provisional API as deprecated, so clients get warnings. What are people's thoughts on the two approaches?
1. The benefit of using mandatory attributes on provisional API is
that you have to explicitly "opt in" to use it so no one can ever
claim they didn't know it was provisional.
2. The benefit of using deprecated tags is that it works more
smoothly with tooling and at still does give some sort of warning
notice, although less direct.
Personally, i still favor using mandatory attributes, because I think it
better captures our use case. But, I'd like to hear what other people think.
Quickly. :-) -> richard On 9/22/10 9:19, Richard S. Hall wrote:
On 9/22/10 6:16, Guillaume Nodet wrote:I'm also not convinced by the mandatory attribute. I do understand the value, but it may cause a lot of burden on our users for not much.If you have another recommendation for making it 100% clear to our users that these packages will not be supported in the future, then speak up. It's not that I want to use mandatory attributes, it's that I don't want to be taken to task in the future for throwing away the API. In that regard, I think there is benefit to using it since people have to go out of their way to use it.Regarding the version number, I was using 0.6.1 because it is only a maintenance release as compared to 0.6.0. The completely incompatible change was from 0.4.0 to 0.6.0, no? Or are you specifically referring to the mandatory attribute? If so, I don't have an issue with it being 0.8.0 if you think the mandatory attribute warrants it, but I don't really think that constitutes a breaking code change...certainly a breaking metadata change.-> richardMandatory attributes are not very common and the tooling might not be prepared to handle those gracefully. For example, I've just hit a big problem with karaf integration tests that use pax-exam, because the mandatory attribute it not automatically added, so all test bundles were failing during resolution ...I've fixed that, but an average user will be in a real trouble if hitting this.On Wed, Sep 22, 2010 at 08:29, Guillaume Nodet<[email protected]> wrote:Do you plan to release gogo as 0.6.1 as indicated in JIRA ?Given the change is fully incompatible, I'd at least bump the minor version ...On Mon, Sep 20, 2010 at 17:50, Richard S. Hall<[email protected]> wrote:On 9/20/10 11:21, Derek Baum wrote:It sounds like we have consensus, so we can probably just move forward.I also favor #1.When we apply this to gogo, it will mean removing the draft RFC-147 APIfromthe 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 revertedthe change in the trunk, as it broke many command providers who importedorg.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 avote?-> richardDerekOn 19 September 2010 17:27, Richard S. Hall<[email protected]> wrote:On 9/18/10 10:34, Felix Meschberger wrote: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.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 weso wish.Forframework, 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 forthis and subprojects can choose to support two APIs if they want. -> richard RegardsFelix Am 17.09.2010 18:35, schrieb Richard S. Hall:For a long time, we've played a little fast and loose with our handlingof 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 leadsdifferent 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 readilyavailable by the OSGi Alliance. Even though some of us are members ofthe 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 provisionalOSGi 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 availableby the OSGi Alliance. Both approaches have their drawbacks. The benefit of (1) is that the legal/IP/etiquette issues and/or concernsare reduced to those associated with normal open source development.For completely new development, like Gogo, this would all happen in non-OSGipackages, while changes to existing packages would need to be done in subclasses in non-OSGi packages. One downside of (1) is that it willalways result in a package name change at the end that will breakexisting clients. For this reason, such experimental packages should beexported 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 towhether or not we can do official releases of subprojects containing provisional OSGi API. Even if we do not modify the API, it still ispotentially 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 mandatoryattributes to warn people. Even then, it still raises issues since wearen't at liberty to evolve the packages freely to include OSGiinternal, 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 resultsin 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 runthe decision by the board first). Thoughts? -> richard-- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
