Re: Handling of provisional OSGi API?
+1 sounds good to me 2014-05-17 9:37 GMT+02:00 David Jencks : > I propose we change the provisional api policy page > http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto > this (markdown source): > > The OSGi Alliance exposes provisional API that may or may not become part > of future OSGI specifications. This policy explains how and when Felix > subprojects may relate to such API. Provisional OSGi API refers to anything > in the `org.osgi.*` package namespace that is not part of a final released > specification. > > ## Policy > 1. No Felix release may contain or refer to provisional OSGI API. > 1. Provisional API may be included and used in unreleased source code, > however the API must be part of a final released OSGI specification before > this felix source may be released. > > 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of > provisional api may be released with these modifications: > > 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` > package name space; this effectively makes it provisional Felix API. > 1. All Felix provisional API must be marked as deprecated. > 1. All Felix provisional API exported from bundles should be exported > with a mandatory attribute of `status="provisional"`. > > ## Discussion > > The first goal of this policy is to completely avoid using provisional > OSGi API in released Felix projects given the potential confusion and > questions by doing so. The second goal is to make the existence of any > released Felix provisional API completely obvious to downstream users and > make it difficult for them to use it unknowingly. However, any such release > is likely to involve numerous problems such as incorrect semantic > versioning or version mismatch between the provisional and eventual osgi > release and bundle version inflation if the felix provisional api is > removed after the OSGI API is released. > > As an example, to provisionally export the > `org.apache.felix.service.metatype` package, the > `Export-Package` statement would look something like this: > > :::xml > > org.apache.felix.service.metatype; version="0.1"; > mandatory="status"; status="provisional" > > > When working with new OSGI specifications, constructing a Felix > provisional API will likely result in parallel package structures between > the provisional OSGi and Felix APIs. When working with existing > specifications, it may be necessary to create extensions to existing OSGi > interfaces in the Felix package namespace. > > Comments? > > thanks > > david jencks > > ps. JB, Guillaume, what exactly are you +1ing? That we keep talking? > That the policy stay the same? Change? > > On May 16, 2014, at 7:56 PM, "Richard S. Hall" > wrote: > > > On 5/16/14, 20:43 , David Jencks wrote: > >> You have a point about specs that don't get released. And in such a > circumstance having something released with org.osgi packages marked > provisional would be sort of a disaster. > >> > >> But if a felix subproject is going to be an osgi ri, it really needs to > be developed with the right package names. Otherwise, for instance, > debugging the conformance test suite will be more or less impossible, as > well as making running the ri against the ct implausible. > > > > I believe we did have this issue with the Config Admin RI and somehow we > managed. > > > >> > >> So I think I'd like the policy to say (sub) projects are strongly > discouraged from releasing anything with a non released osgi spec api no > matter what package it's moved to and how provisional it's marked, but it's > ok to have unreleased org.osgi packages in source as long as either the > spec gets released before any felix release is made or they are removed > before any felix release is made. > > > > I don't think we can leave policy as a recommendation, because then it > still leaves it up to whomever to decide. > > > > Again, I don't have an issue with saying it is okay in source form, but > not in a released artifact. > > > > > >> > >> My next DS commits add the DTO stuff, so unless the policy is changed > they will have to wait on github for a while. > > > > So, make a modified policy proposal and put it up for comments and > ultimately a vote. > > > > -> richard > > > >> > >> thanks > >> david jencks > >> > >> > >> > >> On May 16, 2014, at 2:24 PM, Richard S. Hall > wrote: > >> > >>> There was thought that went into that policy, it wasn't just pulled > out of the air...further, from experience of working on that specs that > didn't make the cut (original OBR and Gogo), I can say the policy does a > good job of avoiding the confusion/complication created in those cases. > >>> > >>> So, working around the policy based on personal whim, doesn't seem > like a good idea...that sort of makes it not a policy. > >>> > >>> However, all policies can be improved. You could argue that the policy > should simply be modified, as David suggests, to say only "relea
Re: Handling of provisional OSGi API?
On 19 May 2014 10:54, Marcel Offermans wrote: > Hello David, > > On 19 May 2014, at 10:22 , David Bosschaert > wrote: > >> On 5/16/14, 20:43 , David Jencks wrote: >>> for instance, debugging the conformance test suite will be more or less >>> impossible, >> >> Yep, if you're writing an RI in Felix and this RI needs to run as part >> of the OSGi CT, it will only work if it uses the official OSGi API. >> As an example take an OSGi CT that looks for a whiteboard service that >> implements the org.osgi.service.http.runtime.HttpServiceRuntime >> interface. >> The CT will not find the implementation if it's renamed to >> org.apache.felix...something. So at least to test the RI as part of >> the CT you need the real API. > > You do, but as far as I know you do not need a release (in the Apache sense > of the word, meaning source code) for that as the OSGi CT only requires you > to submit a binary artifact. And that can easily be produced without doing > any kind of release (and should, because it’s not for public consumption > usually). Yep, correct. When OSGi releases the RIs and CTs they do want to be able to correlate an RI binary to a commit in the source code tree (e.g. by mentioning a tag or commit ID in the manifest), but it doesn't have to be an official release. >> BTW I think it would be good if this policy could also apply to new >> versions of an existing API. E.g. it should also be usable when we >> move the Core API from 1.7 to 1.8 for Core R6. Thought anyone? > > This policy already applies to new versions of an existing API, right? Great. Cheers, David
Re: Handling of provisional OSGi API?
Hello David, On 19 May 2014, at 10:22 , David Bosschaert wrote: > On 5/16/14, 20:43 , David Jencks wrote: >> for instance, debugging the conformance test suite will be more or less >> impossible, > > Yep, if you're writing an RI in Felix and this RI needs to run as part > of the OSGi CT, it will only work if it uses the official OSGi API. > As an example take an OSGi CT that looks for a whiteboard service that > implements the org.osgi.service.http.runtime.HttpServiceRuntime > interface. > The CT will not find the implementation if it's renamed to > org.apache.felix...something. So at least to test the RI as part of > the CT you need the real API. You do, but as far as I know you do not need a release (in the Apache sense of the word, meaning source code) for that as the OSGi CT only requires you to submit a binary artifact. And that can easily be produced without doing any kind of release (and should, because it’s not for public consumption usually). > BTW I think it would be good if this policy could also apply to new > versions of an existing API. E.g. it should also be usable when we > move the Core API from 1.7 to 1.8 for Core R6. Thought anyone? This policy already applies to new versions of an existing API, right? Greetings, Marcel > > Cheers, > > David > > On 19 May 2014 10:05, Marcel Offermans wrote: >> I did not read David’s proposal that way. I think he is saying: >> >> YES, you can code against an API that is under development, as long as you >> do not do any releases (before the API is finalized). >> >> So only if you want to do a release before the API is finalized do you need >> to package it under the Felix namespace and deprecate it (with a provisional >> status). >> >> The only downside I see is that, from the OSGi Alliance point of view, they >> are getting less “real world” use of their reference implementations while >> they are being developed, because this policy makes it impractical to use >> (in production) any API that is still under development. On the other hand, >> it’s not too hard for someone to write a small component that publishes such >> an API itself and “bridges” to the artifact that our project released. I >> think that’s actually a reasonable compromise. >> >> Personally, I could also live with a policy that only requires us to put the >> API in the Felix namespace (and not mark it deprecated or anything). Once an >> artifact has been released, it’s out there anyway. On the other hand, those >> extras are not in anybody’s way and they do serve as a warning, so I’m not >> going to make an argument that we must remove them. >> >> Greetings, Marcel >> >> On 19 May 2014, at 9:24 , Guillaume Nodet wrote: >> >>> The change and your proposal. It seems to restrictive to not allow coding >>> against API that are being developped when not planning to release the >>> project before the API is. >>> >>> >>> 2014-05-17 9:37 GMT+02:00 David Jencks : >>> I propose we change the provisional api policy page http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto this (markdown source): The OSGi Alliance exposes provisional API that may or may not become part of future OSGI specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification. ## Policy 1. No Felix release may contain or refer to provisional OSGI API. 1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGI specification before this felix source may be released. 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications: 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API. 1. All Felix provisional API must be marked as deprecated. 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status="provisional"`. ## Discussion The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and eventual osgi release and bundle version inflation if the felix provisional api is removed after the OSGI API is released. As an example, to provisi
Re: Handling of provisional OSGi API?
On 5/16/14, 20:43 , David Jencks wrote: > for instance, debugging the conformance test suite will be more or less > impossible, Yep, if you're writing an RI in Felix and this RI needs to run as part of the OSGi CT, it will only work if it uses the official OSGi API. As an example take an OSGi CT that looks for a whiteboard service that implements the org.osgi.service.http.runtime.HttpServiceRuntime interface. The CT will not find the implementation if it's renamed to org.apache.felix...something. So at least to test the RI as part of the CT you need the real API. BTW I think it would be good if this policy could also apply to new versions of an existing API. E.g. it should also be usable when we move the Core API from 1.7 to 1.8 for Core R6. Thought anyone? Cheers, David On 19 May 2014 10:05, Marcel Offermans wrote: > I did not read David’s proposal that way. I think he is saying: > > YES, you can code against an API that is under development, as long as you do > not do any releases (before the API is finalized). > > So only if you want to do a release before the API is finalized do you need > to package it under the Felix namespace and deprecate it (with a provisional > status). > > The only downside I see is that, from the OSGi Alliance point of view, they > are getting less “real world” use of their reference implementations while > they are being developed, because this policy makes it impractical to use (in > production) any API that is still under development. On the other hand, it’s > not too hard for someone to write a small component that publishes such an > API itself and “bridges” to the artifact that our project released. I think > that’s actually a reasonable compromise. > > Personally, I could also live with a policy that only requires us to put the > API in the Felix namespace (and not mark it deprecated or anything). Once an > artifact has been released, it’s out there anyway. On the other hand, those > extras are not in anybody’s way and they do serve as a warning, so I’m not > going to make an argument that we must remove them. > > Greetings, Marcel > > On 19 May 2014, at 9:24 , Guillaume Nodet wrote: > >> The change and your proposal. It seems to restrictive to not allow coding >> against API that are being developped when not planning to release the >> project before the API is. >> >> >> 2014-05-17 9:37 GMT+02:00 David Jencks : >> >>> I propose we change the provisional api policy page >>> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto >>> this (markdown source): >>> >>> The OSGi Alliance exposes provisional API that may or may not become part >>> of future OSGI specifications. This policy explains how and when Felix >>> subprojects may relate to such API. Provisional OSGi API refers to anything >>> in the `org.osgi.*` package namespace that is not part of a final released >>> specification. >>> >>> ## Policy >>> 1. No Felix release may contain or refer to provisional OSGI API. >>> 1. Provisional API may be included and used in unreleased source code, >>> however the API must be part of a final released OSGI specification before >>> this felix source may be released. >>> >>> 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of >>> provisional api may be released with these modifications: >>> >>> 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` >>> package name space; this effectively makes it provisional Felix API. >>> 1. All Felix provisional API must be marked as deprecated. >>> 1. All Felix provisional API exported from bundles should be exported >>> with a mandatory attribute of `status="provisional"`. >>> >>> ## Discussion >>> >>> The first goal of this policy is to completely avoid using provisional >>> OSGi API in released Felix projects given the potential confusion and >>> questions by doing so. The second goal is to make the existence of any >>> released Felix provisional API completely obvious to downstream users and >>> make it difficult for them to use it unknowingly. However, any such release >>> is likely to involve numerous problems such as incorrect semantic >>> versioning or version mismatch between the provisional and eventual osgi >>> release and bundle version inflation if the felix provisional api is >>> removed after the OSGI API is released. >>> >>> As an example, to provisionally export the >>> `org.apache.felix.service.metatype` package, the >>> `Export-Package` statement would look something like this: >>> >>>:::xml >>> >>> org.apache.felix.service.metatype; version="0.1"; >>> mandatory="status"; status="provisional" >>> >>> >>> When working with new OSGI specifications, constructing a Felix >>> provisional API will likely result in parallel package structures between >>> the provisional OSGi and Felix APIs. When working with existing >>> specifications, it may be necessary to create extensions to existing OSGi >>> interfaces in the Felix package
Re: Handling of provisional OSGi API?
I did not read David’s proposal that way. I think he is saying: YES, you can code against an API that is under development, as long as you do not do any releases (before the API is finalized). So only if you want to do a release before the API is finalized do you need to package it under the Felix namespace and deprecate it (with a provisional status). The only downside I see is that, from the OSGi Alliance point of view, they are getting less “real world” use of their reference implementations while they are being developed, because this policy makes it impractical to use (in production) any API that is still under development. On the other hand, it’s not too hard for someone to write a small component that publishes such an API itself and “bridges” to the artifact that our project released. I think that’s actually a reasonable compromise. Personally, I could also live with a policy that only requires us to put the API in the Felix namespace (and not mark it deprecated or anything). Once an artifact has been released, it’s out there anyway. On the other hand, those extras are not in anybody’s way and they do serve as a warning, so I’m not going to make an argument that we must remove them. Greetings, Marcel On 19 May 2014, at 9:24 , Guillaume Nodet wrote: > The change and your proposal. It seems to restrictive to not allow coding > against API that are being developped when not planning to release the > project before the API is. > > > 2014-05-17 9:37 GMT+02:00 David Jencks : > >> I propose we change the provisional api policy page >> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto >> this (markdown source): >> >> The OSGi Alliance exposes provisional API that may or may not become part >> of future OSGI specifications. This policy explains how and when Felix >> subprojects may relate to such API. Provisional OSGi API refers to anything >> in the `org.osgi.*` package namespace that is not part of a final released >> specification. >> >> ## Policy >> 1. No Felix release may contain or refer to provisional OSGI API. >> 1. Provisional API may be included and used in unreleased source code, >> however the API must be part of a final released OSGI specification before >> this felix source may be released. >> >> 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of >> provisional api may be released with these modifications: >> >> 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` >> package name space; this effectively makes it provisional Felix API. >> 1. All Felix provisional API must be marked as deprecated. >> 1. All Felix provisional API exported from bundles should be exported >> with a mandatory attribute of `status="provisional"`. >> >> ## Discussion >> >> The first goal of this policy is to completely avoid using provisional >> OSGi API in released Felix projects given the potential confusion and >> questions by doing so. The second goal is to make the existence of any >> released Felix provisional API completely obvious to downstream users and >> make it difficult for them to use it unknowingly. However, any such release >> is likely to involve numerous problems such as incorrect semantic >> versioning or version mismatch between the provisional and eventual osgi >> release and bundle version inflation if the felix provisional api is >> removed after the OSGI API is released. >> >> As an example, to provisionally export the >> `org.apache.felix.service.metatype` package, the >> `Export-Package` statement would look something like this: >> >>:::xml >> >> org.apache.felix.service.metatype; version="0.1"; >> mandatory="status"; status="provisional" >> >> >> When working with new OSGI specifications, constructing a Felix >> provisional API will likely result in parallel package structures between >> the provisional OSGi and Felix APIs. When working with existing >> specifications, it may be necessary to create extensions to existing OSGi >> interfaces in the Felix package namespace. >> >> Comments? >> >> thanks >> >> david jencks >> >> ps. JB, Guillaume, what exactly are you +1ing? That we keep talking? >> That the policy stay the same? Change? >> >> On May 16, 2014, at 7:56 PM, "Richard S. Hall" >> wrote: >> >>> On 5/16/14, 20:43 , David Jencks wrote: You have a point about specs that don't get released. And in such a >> circumstance having something released with org.osgi packages marked >> provisional would be sort of a disaster. But if a felix subproject is going to be an osgi ri, it really needs to >> be developed with the right package names. Otherwise, for instance, >> debugging the conformance test suite will be more or less impossible, as >> well as making running the ri against the ct implausible. >>> >>> I believe we did have this issue with the Config Admin RI and somehow we >> managed. >>> So I think I'd like the policy to say (su
Re: Handling of provisional OSGi API?
The change and your proposal. It seems to restrictive to not allow coding against API that are being developped when not planning to release the project before the API is. 2014-05-17 9:37 GMT+02:00 David Jencks : > I propose we change the provisional api policy page > http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto > this (markdown source): > > The OSGi Alliance exposes provisional API that may or may not become part > of future OSGI specifications. This policy explains how and when Felix > subprojects may relate to such API. Provisional OSGi API refers to anything > in the `org.osgi.*` package namespace that is not part of a final released > specification. > > ## Policy > 1. No Felix release may contain or refer to provisional OSGI API. > 1. Provisional API may be included and used in unreleased source code, > however the API must be part of a final released OSGI specification before > this felix source may be released. > > 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of > provisional api may be released with these modifications: > > 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` > package name space; this effectively makes it provisional Felix API. > 1. All Felix provisional API must be marked as deprecated. > 1. All Felix provisional API exported from bundles should be exported > with a mandatory attribute of `status="provisional"`. > > ## Discussion > > The first goal of this policy is to completely avoid using provisional > OSGi API in released Felix projects given the potential confusion and > questions by doing so. The second goal is to make the existence of any > released Felix provisional API completely obvious to downstream users and > make it difficult for them to use it unknowingly. However, any such release > is likely to involve numerous problems such as incorrect semantic > versioning or version mismatch between the provisional and eventual osgi > release and bundle version inflation if the felix provisional api is > removed after the OSGI API is released. > > As an example, to provisionally export the > `org.apache.felix.service.metatype` package, the > `Export-Package` statement would look something like this: > > :::xml > > org.apache.felix.service.metatype; version="0.1"; > mandatory="status"; status="provisional" > > > When working with new OSGI specifications, constructing a Felix > provisional API will likely result in parallel package structures between > the provisional OSGi and Felix APIs. When working with existing > specifications, it may be necessary to create extensions to existing OSGi > interfaces in the Felix package namespace. > > Comments? > > thanks > > david jencks > > ps. JB, Guillaume, what exactly are you +1ing? That we keep talking? > That the policy stay the same? Change? > > On May 16, 2014, at 7:56 PM, "Richard S. Hall" > wrote: > > > On 5/16/14, 20:43 , David Jencks wrote: > >> You have a point about specs that don't get released. And in such a > circumstance having something released with org.osgi packages marked > provisional would be sort of a disaster. > >> > >> But if a felix subproject is going to be an osgi ri, it really needs to > be developed with the right package names. Otherwise, for instance, > debugging the conformance test suite will be more or less impossible, as > well as making running the ri against the ct implausible. > > > > I believe we did have this issue with the Config Admin RI and somehow we > managed. > > > >> > >> So I think I'd like the policy to say (sub) projects are strongly > discouraged from releasing anything with a non released osgi spec api no > matter what package it's moved to and how provisional it's marked, but it's > ok to have unreleased org.osgi packages in source as long as either the > spec gets released before any felix release is made or they are removed > before any felix release is made. > > > > I don't think we can leave policy as a recommendation, because then it > still leaves it up to whomever to decide. > > > > Again, I don't have an issue with saying it is okay in source form, but > not in a released artifact. > > > > > >> > >> My next DS commits add the DTO stuff, so unless the policy is changed > they will have to wait on github for a while. > > > > So, make a modified policy proposal and put it up for comments and > ultimately a vote. > > > > -> richard > > > >> > >> thanks > >> david jencks > >> > >> > >> > >> On May 16, 2014, at 2:24 PM, Richard S. Hall > wrote: > >> > >>> There was thought that went into that policy, it wasn't just pulled > out of the air...further, from experience of working on that specs that > didn't make the cut (original OBR and Gogo), I can say the policy does a > good job of avoiding the confusion/complication created in those cases. > >>> > >>> So, working around the policy based on personal whim, doesn't seem > like a good idea...that sort of makes it not a polic
Re: Handling of provisional OSGi API?
Other than a few minor capitalization issues, it looks ok to me. -> richard On 5/17/14, 03:37 , David Jencks wrote: I propose we change the provisional api policy page http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html to this (markdown source): The OSGi Alliance exposes provisional API that may or may not become part of future OSGI specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification. ## Policy 1. No Felix release may contain or refer to provisional OSGI API. 1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGI specification before this felix source may be released. 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications: 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API. 1. All Felix provisional API must be marked as deprecated. 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status="provisional"`. ## Discussion The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and eventual osgi release and bundle version inflation if the felix provisional api is removed after the OSGI API is released. As an example, to provisionally export the `org.apache.felix.service.metatype` package, the `Export-Package` statement would look something like this: :::xml org.apache.felix.service.metatype; version="0.1"; mandatory="status"; status="provisional" When working with new OSGI specifications, constructing a Felix provisional API will likely result in parallel package structures between the provisional OSGi and Felix APIs. When working with existing specifications, it may be necessary to create extensions to existing OSGi interfaces in the Felix package namespace. Comments? thanks david jencks ps. JB, Guillaume, what exactly are you +1ing? That we keep talking? That the policy stay the same? Change? On May 16, 2014, at 7:56 PM, "Richard S. Hall" wrote: On 5/16/14, 20:43 , David Jencks wrote: You have a point about specs that don't get released. And in such a circumstance having something released with org.osgi packages marked provisional would be sort of a disaster. But if a felix subproject is going to be an osgi ri, it really needs to be developed with the right package names. Otherwise, for instance, debugging the conformance test suite will be more or less impossible, as well as making running the ri against the ct implausible. I believe we did have this issue with the Config Admin RI and somehow we managed. So I think I'd like the policy to say (sub) projects are strongly discouraged from releasing anything with a non released osgi spec api no matter what package it's moved to and how provisional it's marked, but it's ok to have unreleased org.osgi packages in source as long as either the spec gets released before any felix release is made or they are removed before any felix release is made. I don't think we can leave policy as a recommendation, because then it still leaves it up to whomever to decide. Again, I don't have an issue with saying it is okay in source form, but not in a released artifact. My next DS commits add the DTO stuff, so unless the policy is changed they will have to wait on github for a while. So, make a modified policy proposal and put it up for comments and ultimately a vote. -> richard thanks david jencks On May 16, 2014, at 2:24 PM, Richard S. Hall wrote: There was thought that went into that policy, it wasn't just pulled out of the air...further, from experience of working on that specs that didn't make the cut (original OBR and Gogo), I can say the policy does a good job of avoiding the confusion/complication created in those cases. So, working around the policy based on personal whim, doesn't seem like a good idea...that sort of makes it not a policy. However, all policies can be improved. You could argue that the policy should simply be modified, as David suggests, to say only "released" subprojects must not contain provisional API. I'd personally be fine with that, but such a subproject would still have to be fine with not having an official release until the specs are
Re: Handling of provisional OSGi API?
I propose we change the provisional api policy page http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html to this (markdown source): The OSGi Alliance exposes provisional API that may or may not become part of future OSGI specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification. ## Policy 1. No Felix release may contain or refer to provisional OSGI API. 1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGI specification before this felix source may be released. 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications: 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API. 1. All Felix provisional API must be marked as deprecated. 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status="provisional"`. ## Discussion The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and eventual osgi release and bundle version inflation if the felix provisional api is removed after the OSGI API is released. As an example, to provisionally export the `org.apache.felix.service.metatype` package, the `Export-Package` statement would look something like this: :::xml org.apache.felix.service.metatype; version="0.1"; mandatory="status"; status="provisional" When working with new OSGI specifications, constructing a Felix provisional API will likely result in parallel package structures between the provisional OSGi and Felix APIs. When working with existing specifications, it may be necessary to create extensions to existing OSGi interfaces in the Felix package namespace. Comments? thanks david jencks ps. JB, Guillaume, what exactly are you +1ing? That we keep talking? That the policy stay the same? Change? On May 16, 2014, at 7:56 PM, "Richard S. Hall" wrote: > On 5/16/14, 20:43 , David Jencks wrote: >> You have a point about specs that don't get released. And in such a >> circumstance having something released with org.osgi packages marked >> provisional would be sort of a disaster. >> >> But if a felix subproject is going to be an osgi ri, it really needs to be >> developed with the right package names. Otherwise, for instance, debugging >> the conformance test suite will be more or less impossible, as well as >> making running the ri against the ct implausible. > > I believe we did have this issue with the Config Admin RI and somehow we > managed. > >> >> So I think I'd like the policy to say (sub) projects are strongly >> discouraged from releasing anything with a non released osgi spec api no >> matter what package it's moved to and how provisional it's marked, but it's >> ok to have unreleased org.osgi packages in source as long as either the spec >> gets released before any felix release is made or they are removed before >> any felix release is made. > > I don't think we can leave policy as a recommendation, because then it still > leaves it up to whomever to decide. > > Again, I don't have an issue with saying it is okay in source form, but not > in a released artifact. > > >> >> My next DS commits add the DTO stuff, so unless the policy is changed they >> will have to wait on github for a while. > > So, make a modified policy proposal and put it up for comments and ultimately > a vote. > > -> richard > >> >> thanks >> david jencks >> >> >> >> On May 16, 2014, at 2:24 PM, Richard S. Hall wrote: >> >>> There was thought that went into that policy, it wasn't just pulled out of >>> the air...further, from experience of working on that specs that didn't >>> make the cut (original OBR and Gogo), I can say the policy does a good job >>> of avoiding the confusion/complication created in those cases. >>> >>> So, working around the policy based on personal whim, doesn't seem like a >>> good idea...that sort of makes it not a policy. >>> >>> However, all policies can be improved. You could argue that the policy >>> should simply be modified, as David suggests, to say only "released" >>> subprojects must not contain provisional API. >>> >>> I'd personally be fine with that, but such a subproject would still have to >>> be fine with not havin
Re: Handling of provisional OSGi API?
On 5/16/14, 20:43 , David Jencks wrote: You have a point about specs that don't get released. And in such a circumstance having something released with org.osgi packages marked provisional would be sort of a disaster. But if a felix subproject is going to be an osgi ri, it really needs to be developed with the right package names. Otherwise, for instance, debugging the conformance test suite will be more or less impossible, as well as making running the ri against the ct implausible. I believe we did have this issue with the Config Admin RI and somehow we managed. So I think I'd like the policy to say (sub) projects are strongly discouraged from releasing anything with a non released osgi spec api no matter what package it's moved to and how provisional it's marked, but it's ok to have unreleased org.osgi packages in source as long as either the spec gets released before any felix release is made or they are removed before any felix release is made. I don't think we can leave policy as a recommendation, because then it still leaves it up to whomever to decide. Again, I don't have an issue with saying it is okay in source form, but not in a released artifact. My next DS commits add the DTO stuff, so unless the policy is changed they will have to wait on github for a while. So, make a modified policy proposal and put it up for comments and ultimately a vote. -> richard thanks david jencks On May 16, 2014, at 2:24 PM, Richard S. Hall wrote: There was thought that went into that policy, it wasn't just pulled out of the air...further, from experience of working on that specs that didn't make the cut (original OBR and Gogo), I can say the policy does a good job of avoiding the confusion/complication created in those cases. So, working around the policy based on personal whim, doesn't seem like a good idea...that sort of makes it not a policy. However, all policies can be improved. You could argue that the policy should simply be modified, as David suggests, to say only "released" subprojects must not contain provisional API. I'd personally be fine with that, but such a subproject would still have to be fine with not having an official release until the specs are final. -> richard On 5/16/14, 13:59 , David Jencks wrote: Well, I pretty much disagree with the existing policy being good or nice, but I think I agree with your proposal. I think that there should be very different policy for the svn tree and for releases. I don't think it's a very good idea to have a release with a provisional osgi api, whether or not it's had its packages shaded. However if we decide we need to do this I think _either_ renaming the packages _or_ marking the packages provisional should be sufficient, not both. For the svn tree, I think it's fine to just copy the osgi draft source into some appropriate location and build it as part of the project. The svn tree is not for general consumption, if you use it you are supposed to know what you are doing and you certainly aren't supposed to rely on it for production without doing your own deternimation that it is entirely suitable, since it comes with no assurances of anything from apache. We just shouldn't release anything in this state: either the spec gets released first, or we mark the spec packages provisional or rename them. I have the same problem with the felix ds/rfc 190 work, with the new runtime and dto packages, and realistically for me the options are either changing the policy, or keeping my work visible on github until the spec is released. I don't have time or interest to investigate, but it might be possible to use the maven shade plugin to rename the packages in byte code. I imagine we'd have to run bnd after this step. I don't know if the shading can be done to integration tests as well so the instructions to bnd don't have to be duplicated with and without the mangled package names so we can create an unshaded bundle for unshaded integration tests. thanks for reminding me to think about this before I committed :-) david jencks On May 15, 2014, at 11:14 PM, Carsten Ziegeler wrote: Hi, right now we have a policy for handling provisional OSGi API (API that is currently drafted in the OSGi expert groups but not final or officially released yet): http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html While the policy is good and nice, it requires to rename the packages from an OSGi namespace to an Apache one for the reasons stated in the policy. However, this creates a burden for people using this stuff, e.g. when writing tests as these need to be refactored later on anyway. The reference implementation of the new Http Service (RFC 189) will be done as part of Apache Felix and we would like to start working on this in the open. Therefore we need to commit the current version of the API draft somewhere. I think if we do this in the whiteboard section, i
Re: Handling of provisional OSGi API?
+1 Regards JB On 05/16/2014 11:24 PM, Richard S. Hall wrote: There was thought that went into that policy, it wasn't just pulled out of the air...further, from experience of working on that specs that didn't make the cut (original OBR and Gogo), I can say the policy does a good job of avoiding the confusion/complication created in those cases. So, working around the policy based on personal whim, doesn't seem like a good idea...that sort of makes it not a policy. However, all policies can be improved. You could argue that the policy should simply be modified, as David suggests, to say only "released" subprojects must not contain provisional API. I'd personally be fine with that, but such a subproject would still have to be fine with not having an official release until the specs are final. -> richard On 5/16/14, 13:59 , David Jencks wrote: Well, I pretty much disagree with the existing policy being good or nice, but I think I agree with your proposal. I think that there should be very different policy for the svn tree and for releases. I don't think it's a very good idea to have a release with a provisional osgi api, whether or not it's had its packages shaded. However if we decide we need to do this I think _either_ renaming the packages _or_ marking the packages provisional should be sufficient, not both. For the svn tree, I think it's fine to just copy the osgi draft source into some appropriate location and build it as part of the project. The svn tree is not for general consumption, if you use it you are supposed to know what you are doing and you certainly aren't supposed to rely on it for production without doing your own deternimation that it is entirely suitable, since it comes with no assurances of anything from apache. We just shouldn't release anything in this state: either the spec gets released first, or we mark the spec packages provisional or rename them. I have the same problem with the felix ds/rfc 190 work, with the new runtime and dto packages, and realistically for me the options are either changing the policy, or keeping my work visible on github until the spec is released. I don't have time or interest to investigate, but it might be possible to use the maven shade plugin to rename the packages in byte code. I imagine we'd have to run bnd after this step. I don't know if the shading can be done to integration tests as well so the instructions to bnd don't have to be duplicated with and without the mangled package names so we can create an unshaded bundle for unshaded integration tests. thanks for reminding me to think about this before I committed :-) david jencks On May 15, 2014, at 11:14 PM, Carsten Ziegeler wrote: Hi, right now we have a policy for handling provisional OSGi API (API that is currently drafted in the OSGi expert groups but not final or officially released yet): http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html While the policy is good and nice, it requires to rename the packages from an OSGi namespace to an Apache one for the reasons stated in the policy. However, this creates a burden for people using this stuff, e.g. when writing tests as these need to be refactored later on anyway. The reference implementation of the new Http Service (RFC 189) will be done as part of Apache Felix and we would like to start working on this in the open. Therefore we need to commit the current version of the API draft somewhere. I think if we do this in the whiteboard section, it should be clear enough that the API is provisional and we don't need to rename the packages. We can also add all kinds of disclaimers/readmes etc. But before doing so, I would like to get the general feeling about this. So, wdyt? Thanks Carsten -- Carsten Ziegeler cziege...@apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Handling of provisional OSGi API?
You have a point about specs that don't get released. And in such a circumstance having something released with org.osgi packages marked provisional would be sort of a disaster. But if a felix subproject is going to be an osgi ri, it really needs to be developed with the right package names. Otherwise, for instance, debugging the conformance test suite will be more or less impossible, as well as making running the ri against the ct implausible. So I think I'd like the policy to say (sub) projects are strongly discouraged from releasing anything with a non released osgi spec api no matter what package it's moved to and how provisional it's marked, but it's ok to have unreleased org.osgi packages in source as long as either the spec gets released before any felix release is made or they are removed before any felix release is made. My next DS commits add the DTO stuff, so unless the policy is changed they will have to wait on github for a while. thanks david jencks On May 16, 2014, at 2:24 PM, Richard S. Hall wrote: > There was thought that went into that policy, it wasn't just pulled out of > the air...further, from experience of working on that specs that didn't make > the cut (original OBR and Gogo), I can say the policy does a good job of > avoiding the confusion/complication created in those cases. > > So, working around the policy based on personal whim, doesn't seem like a > good idea...that sort of makes it not a policy. > > However, all policies can be improved. You could argue that the policy should > simply be modified, as David suggests, to say only "released" subprojects > must not contain provisional API. > > I'd personally be fine with that, but such a subproject would still have to > be fine with not having an official release until the specs are final. > > -> richard > > On 5/16/14, 13:59 , David Jencks wrote: >> Well, I pretty much disagree with the existing policy being good or nice, >> but I think I agree with your proposal. >> >> I think that there should be very different policy for the svn tree and for >> releases. I don't think it's a very good idea to have a release with a >> provisional osgi api, whether or not it's had its packages shaded. However >> if we decide we need to do this I think _either_ renaming the packages _or_ >> marking the packages provisional should be sufficient, not both. >> >> For the svn tree, I think it's fine to just copy the osgi draft source into >> some appropriate location and build it as part of the project. The svn tree >> is not for general consumption, if you use it you are supposed to know what >> you are doing and you certainly aren't supposed to rely on it for production >> without doing your own deternimation that it is entirely suitable, since it >> comes with no assurances of anything from apache. We just shouldn't release >> anything in this state: either the spec gets released first, or we mark the >> spec packages provisional or rename them. >> >> I have the same problem with the felix ds/rfc 190 work, with the new >> runtime and dto packages, and realistically for me the options are either >> changing the policy, or keeping my work visible on github until the spec is >> released. >> >> I don't have time or interest to investigate, but it might be possible to >> use the maven shade plugin to rename the packages in byte code. I imagine >> we'd have to run bnd after this step. I don't know if the shading can be >> done to integration tests as well so the instructions to bnd don't have to >> be duplicated with and without the mangled package names so we can create an >> unshaded bundle for unshaded integration tests. >> >> thanks for reminding me to think about this before I committed :-) >> >> david jencks >> >> On May 15, 2014, at 11:14 PM, Carsten Ziegeler wrote: >> >>> Hi, >>> >>> right now we have a policy for handling provisional OSGi API (API that is >>> currently drafted in the OSGi expert groups but not final or officially >>> released yet): >>> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html >>> >>> While the policy is good and nice, it requires to rename the packages from >>> an OSGi namespace to an Apache one for the reasons stated in the policy. >>> However, this creates a burden for people using this stuff, e.g. when >>> writing tests as these need to be refactored later on anyway. >>> >>> The reference implementation of the new Http Service (RFC 189) will be done >>> as part of Apache Felix and we would like to start working on this in the >>> open. Therefore we need to commit the current version of the API draft >>> somewhere. I think if we do this in the whiteboard section, it should be >>> clear enough that the API is provisional and we don't need to rename the >>> packages. We can also add all kinds of disclaimers/readmes etc. >>> But before doing so, I would like to get the general feeling about this. >>> >>> So, wdyt
Re: Handling of provisional OSGi API?
+1 2014-05-16 23:24 GMT+02:00 Richard S. Hall : > There was thought that went into that policy, it wasn't just pulled out of > the air...further, from experience of working on that specs that didn't > make the cut (original OBR and Gogo), I can say the policy does a good job > of avoiding the confusion/complication created in those cases. > > So, working around the policy based on personal whim, doesn't seem like a > good idea...that sort of makes it not a policy. > > However, all policies can be improved. You could argue that the policy > should simply be modified, as David suggests, to say only "released" > subprojects must not contain provisional API. > > I'd personally be fine with that, but such a subproject would still have > to be fine with not having an official release until the specs are final. > > -> richard > > > On 5/16/14, 13:59 , David Jencks wrote: > >> Well, I pretty much disagree with the existing policy being good or nice, >> but I think I agree with your proposal. >> >> I think that there should be very different policy for the svn tree and >> for releases. I don't think it's a very good idea to have a release with a >> provisional osgi api, whether or not it's had its packages shaded. However >> if we decide we need to do this I think _either_ renaming the packages _or_ >> marking the packages provisional should be sufficient, not both. >> >> For the svn tree, I think it's fine to just copy the osgi draft source >> into some appropriate location and build it as part of the project. The >> svn tree is not for general consumption, if you use it you are supposed to >> know what you are doing and you certainly aren't supposed to rely on it for >> production without doing your own deternimation that it is entirely >> suitable, since it comes with no assurances of anything from apache. We >> just shouldn't release anything in this state: either the spec gets >> released first, or we mark the spec packages provisional or rename them. >> >> I have the same problem with the felix ds/rfc 190 work, with the new >> runtime and dto packages, and realistically for me the options are either >> changing the policy, or keeping my work visible on github until the spec is >> released. >> >> I don't have time or interest to investigate, but it might be possible to >> use the maven shade plugin to rename the packages in byte code. I imagine >> we'd have to run bnd after this step. I don't know if the shading can be >> done to integration tests as well so the instructions to bnd don't have to >> be duplicated with and without the mangled package names so we can create >> an unshaded bundle for unshaded integration tests. >> >> thanks for reminding me to think about this before I committed :-) >> >> david jencks >> >> On May 15, 2014, at 11:14 PM, Carsten Ziegeler >> wrote: >> >> Hi, >>> >>> right now we have a policy for handling provisional OSGi API (API that is >>> currently drafted in the OSGi expert groups but not final or officially >>> released yet): >>> http://felix.apache.org/documentation/development/ >>> provisional-osgi-api-policy.html >>> >>> While the policy is good and nice, it requires to rename the packages >>> from >>> an OSGi namespace to an Apache one for the reasons stated in the policy. >>> However, this creates a burden for people using this stuff, e.g. when >>> writing tests as these need to be refactored later on anyway. >>> >>> The reference implementation of the new Http Service (RFC 189) will be >>> done >>> as part of Apache Felix and we would like to start working on this in the >>> open. Therefore we need to commit the current version of the API draft >>> somewhere. I think if we do this in the whiteboard section, it should be >>> clear enough that the API is provisional and we don't need to rename the >>> packages. We can also add all kinds of disclaimers/readmes etc. >>> But before doing so, I would like to get the general feeling about this. >>> >>> So, wdyt? >>> >>> Thanks >>> Carsten >>> -- >>> Carsten Ziegeler >>> cziege...@apache.org >>> >> >
Re: Handling of provisional OSGi API?
There was thought that went into that policy, it wasn't just pulled out of the air...further, from experience of working on that specs that didn't make the cut (original OBR and Gogo), I can say the policy does a good job of avoiding the confusion/complication created in those cases. So, working around the policy based on personal whim, doesn't seem like a good idea...that sort of makes it not a policy. However, all policies can be improved. You could argue that the policy should simply be modified, as David suggests, to say only "released" subprojects must not contain provisional API. I'd personally be fine with that, but such a subproject would still have to be fine with not having an official release until the specs are final. -> richard On 5/16/14, 13:59 , David Jencks wrote: Well, I pretty much disagree with the existing policy being good or nice, but I think I agree with your proposal. I think that there should be very different policy for the svn tree and for releases. I don't think it's a very good idea to have a release with a provisional osgi api, whether or not it's had its packages shaded. However if we decide we need to do this I think _either_ renaming the packages _or_ marking the packages provisional should be sufficient, not both. For the svn tree, I think it's fine to just copy the osgi draft source into some appropriate location and build it as part of the project. The svn tree is not for general consumption, if you use it you are supposed to know what you are doing and you certainly aren't supposed to rely on it for production without doing your own deternimation that it is entirely suitable, since it comes with no assurances of anything from apache. We just shouldn't release anything in this state: either the spec gets released first, or we mark the spec packages provisional or rename them. I have the same problem with the felix ds/rfc 190 work, with the new runtime and dto packages, and realistically for me the options are either changing the policy, or keeping my work visible on github until the spec is released. I don't have time or interest to investigate, but it might be possible to use the maven shade plugin to rename the packages in byte code. I imagine we'd have to run bnd after this step. I don't know if the shading can be done to integration tests as well so the instructions to bnd don't have to be duplicated with and without the mangled package names so we can create an unshaded bundle for unshaded integration tests. thanks for reminding me to think about this before I committed :-) david jencks On May 15, 2014, at 11:14 PM, Carsten Ziegeler wrote: Hi, right now we have a policy for handling provisional OSGi API (API that is currently drafted in the OSGi expert groups but not final or officially released yet): http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html While the policy is good and nice, it requires to rename the packages from an OSGi namespace to an Apache one for the reasons stated in the policy. However, this creates a burden for people using this stuff, e.g. when writing tests as these need to be refactored later on anyway. The reference implementation of the new Http Service (RFC 189) will be done as part of Apache Felix and we would like to start working on this in the open. Therefore we need to commit the current version of the API draft somewhere. I think if we do this in the whiteboard section, it should be clear enough that the API is provisional and we don't need to rename the packages. We can also add all kinds of disclaimers/readmes etc. But before doing so, I would like to get the general feeling about this. So, wdyt? Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Handling of provisional OSGi API?
Well, I pretty much disagree with the existing policy being good or nice, but I think I agree with your proposal. I think that there should be very different policy for the svn tree and for releases. I don't think it's a very good idea to have a release with a provisional osgi api, whether or not it's had its packages shaded. However if we decide we need to do this I think _either_ renaming the packages _or_ marking the packages provisional should be sufficient, not both. For the svn tree, I think it's fine to just copy the osgi draft source into some appropriate location and build it as part of the project. The svn tree is not for general consumption, if you use it you are supposed to know what you are doing and you certainly aren't supposed to rely on it for production without doing your own deternimation that it is entirely suitable, since it comes with no assurances of anything from apache. We just shouldn't release anything in this state: either the spec gets released first, or we mark the spec packages provisional or rename them. I have the same problem with the felix ds/rfc 190 work, with the new runtime and dto packages, and realistically for me the options are either changing the policy, or keeping my work visible on github until the spec is released. I don't have time or interest to investigate, but it might be possible to use the maven shade plugin to rename the packages in byte code. I imagine we'd have to run bnd after this step. I don't know if the shading can be done to integration tests as well so the instructions to bnd don't have to be duplicated with and without the mangled package names so we can create an unshaded bundle for unshaded integration tests. thanks for reminding me to think about this before I committed :-) david jencks On May 15, 2014, at 11:14 PM, Carsten Ziegeler wrote: > Hi, > > right now we have a policy for handling provisional OSGi API (API that is > currently drafted in the OSGi expert groups but not final or officially > released yet): > http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html > > While the policy is good and nice, it requires to rename the packages from > an OSGi namespace to an Apache one for the reasons stated in the policy. > However, this creates a burden for people using this stuff, e.g. when > writing tests as these need to be refactored later on anyway. > > The reference implementation of the new Http Service (RFC 189) will be done > as part of Apache Felix and we would like to start working on this in the > open. Therefore we need to commit the current version of the API draft > somewhere. I think if we do this in the whiteboard section, it should be > clear enough that the API is provisional and we don't need to rename the > packages. We can also add all kinds of disclaimers/readmes etc. > But before doing so, I would like to get the general feeling about this. > > So, wdyt? > > Thanks > Carsten > -- > Carsten Ziegeler > cziege...@apache.org
Handling of provisional OSGi API?
Hi, right now we have a policy for handling provisional OSGi API (API that is currently drafted in the OSGi expert groups but not final or officially released yet): http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html While the policy is good and nice, it requires to rename the packages from an OSGi namespace to an Apache one for the reasons stated in the policy. However, this creates a burden for people using this stuff, e.g. when writing tests as these need to be refactored later on anyway. The reference implementation of the new Http Service (RFC 189) will be done as part of Apache Felix and we would like to start working on this in the open. Therefore we need to commit the current version of the API draft somewhere. I think if we do this in the whiteboard section, it should be clear enough that the API is provisional and we don't need to rename the packages. We can also add all kinds of disclaimers/readmes etc. But before doing so, I would like to get the general feeling about this. So, wdyt? Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Handling of provisional OSGi API
just going to push forward for now with what we have in trunk, which is using mandatory attributes. We can continue to refine our policy and when we are done, we can do another release to reflect it even if it means doing another one next week. So, to summarize, we now have three options: 1. Just mandatory attributes. 2. Just deprecated tags. 3. Both. After Tom's arguments, I'm probably now leaning toward #3. -> richard 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. -> richard Mandatory 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 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 wrote: 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 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
Re: Handling of provisional OSGi API
do another release to reflect it even if it means doing another one next week. So, to summarize, we now have three options: 1. Just mandatory attributes. 2. Just deprecated tags. 3. Both. After Tom's arguments, I'm probably now leaning toward #3. -> richard 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. -> richard Mandatory 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 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 wrote: 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 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 Go
Re: Handling of provisional OSGi API
mmendation 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. >>>>>>>>>> >>>>>>>>>> -> richard >>>>>>>>>> >>>>>>>>>>> Mandatory 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 >>>>>>>>>>> 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 wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 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
Re: Handling of provisional OSGi API
uments, I'm probably now leaning toward #3. -> richard 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. -> richard Mandatory 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 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 wrote: 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 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
Re: Handling of provisional OSGi API
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 >>>>>>>>> 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 wrote: >>>>>>>>>>> >>>>>>>>>>> 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 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 >>>>>>>>>>
Re: Handling of provisional OSGi API
e 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. ->richard Mandatory 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 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 wrote: 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 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 a
Re: Handling of provisional OSGi API
butes. >>>> 2. Just deprecated tags. >>>> 3. Both. >>>> >>>> After Tom's arguments, I'm probably now leaning toward #3. >>>> >>>> -> richard >>>> >>>>> 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. >>>>>> >>>>>> -> richard >>>>>> >>>>>>> Mandatory 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 >>>>>>> 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 wrote: >>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>
Re: Handling of provisional OSGi API
#x27;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. >>>>> >>>>> -> richard >>>>> >>>>>>Mandatory 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 >>>>>> 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 wrote: >>>>>>>>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 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. >>>>>>>>>>> >>>>>>>>>> Fro
Re: Handling of provisional OSGi API
l 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 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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Handling of provisional OSGi API
>>>>>>> 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. >>>>>>> Hallwrote: >>>>>>> >>>>>>>> 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
Re: Handling of provisional OSGi API
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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Handling of provisional OSGi API
Hopefully, I can get some quick feedback on this since I want to do a release... 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. -> richard Mandatory 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 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 wrote: 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. Hallwrote: 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
Re: Handling of provisional OSGi API
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. -> richard Mandatory 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 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 wrote: 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. Hallwrote: 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 downsi
Re: Handling of provisional OSGi API
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. Mandatory 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 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 wrote: >> 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 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. >>>>>> >>
Re: Handling of provisional OSGi API
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 wrote: > 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 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
Re: Handling of provisional OSGi API
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 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
Re: Handling of provisional OSGi API
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? Derek On 19 September 2010 17:27, Richard S. Hall 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 >>> >>>
Re: Handling of provisional OSGi API
+1 for #1 regards, Karl On Sun, Sep 19, 2010 at 6:27 PM, Richard S. Hall 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 >>> > -- Karl Pauls karlpa...@gmail.com
Re: Handling of provisional OSGi API
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
Re: Handling of provisional OSGi API
On 9/18/10 11:20, Guillaume Nodet wrote: I'd go for #1 too because it gives us more flexibility without any risks. I suppose #1 could also contain cases where enhancements to an existing api are done by creating interfaces in the org.apache.felix namespace inheriting the org.osgi ones ... provided that we don't touch the osgi ones (meaning that they are officialy published apis). Yes, that was my thinking as well. -> richard On Sat, Sep 18, 2010 at 19: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. 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
Re: Handling of provisional OSGi API
I'd go for #1 too because it gives us more flexibility without any risks. I suppose #1 could also contain cases where enhancements to an existing api are done by creating interfaces in the org.apache.felix namespace inheriting the org.osgi ones ... provided that we don't touch the osgi ones (meaning that they are officialy published apis). On Sat, Sep 18, 2010 at 19: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. > > 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 >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Handling of provisional OSGi API
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. 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 >
Re: Handling of provisional OSGi API
On 9/17/10 13:41, Marcel Offermans wrote: On 17 Sep 2010, at 22:27 , Richard S. Hall wrote: On 9/17/10 12:54, Marcel Offermans wrote: On 17 Sep 2010, at 21:12 , Richard S. Hall wrote: On 9/17/10 12:11, Richard S. Hall wrote: On 9/17/10 11:36, Marcel Offermans wrote: On 17 Sep 2010, at 18:35 , Richard S. Hall wrote: 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). I prefer (1) too. I could see us combine (1) with (2), releasing implementations with both our own APIs which gives us the freedom to experiment with a new API whilst still "supporting what's provided by public releases of draft specs. However, this doesn't avoid the IP grey of releasing "unofficial" APIs in our "official" releases. Does the OSGi alliance disallow the inclusion of these "unofficial" APIs? Effectively, option (2) is a hybrid approach, since we couldn't make modifications in the provisional API unless it were available in a public spec snapshot, so any modifications would have to be done in felix package namespace. Which sort of makes (2) the worst of both worlds. Well, if the snapshots are so outdated that it does not make sense to implement them, then we should not even try. In that case, just stick to (1). Sometimes it is not an issue of being out of date. If we want to implement a feature for potential inclusion into an RFC, then we run into the same issue if we add the feature to an existing OSGi API (whether it is provisional or not). I think that the versioning policy that the OSGi Alliance uses leaves us little room here, so again we should probably go to (1). I mean, let's say that spec 1.6 is the latest stable release and there is a draft for 1.7 then there is no number in between that we could use to indicate we're past 1.6 but not yet at 1.7. Nor do we have the authority to say what that version should be even if there was a number in between. I guess the other point would be for the OSGi Alliance to just develop new RFCs out in the open, but as long as they're not, it's probably safer to ignore them if it could cause problems otherwise. Well, we don't want to ignore them since we want to implement the provisional specs and get experience with them. It is just difficult since our downstream users have no way of knowing what is official OSGi API and what isn't if we ship with provisional and/or modified org.osgi packages. We can always simply not release experimental code / provisional specs, keep them in an experimental branch if we want to still maintain an existing stable release. Yes, that is another approach, but one that I wouldn't favor since it creates an extra burden on us to maintain a separate branch and then later figure out how to merge them. Even following option (1), it's still a tricky balancing act, especially in cases where we might actually provide the RI, such as Gogo or CM. But this is more difficult for us since we release early and often as opposed to Eclipse which releases yearly. As long as we release in our own namespace, I don't see the problem. Let's say we do an experimental release of CM. We would release it as a bundle exporting org.apache.felix.service.cm. The only "tricky" part is that consumer bundles would have to use the packages in our namespace, so it would probably mean they'd have to be written specifically for our implementation. But that's probably the best way to experiment safely anyway. Agreed. -> richard Greetings, Marcel
Re: Handling of provisional OSGi API
On 17 Sep 2010, at 22:27 , Richard S. Hall wrote: > On 9/17/10 12:54, Marcel Offermans wrote: >> On 17 Sep 2010, at 21:12 , Richard S. Hall wrote: >>> On 9/17/10 12:11, Richard S. Hall wrote: On 9/17/10 11:36, Marcel Offermans wrote: > On 17 Sep 2010, at 18:35 , Richard S. Hall wrote: > >> 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). > I prefer (1) too. > > I could see us combine (1) with (2), releasing implementations with both > our own APIs which gives us the freedom to experiment with a new API > whilst still "supporting what's provided by public releases of draft > specs. However, this doesn't avoid the IP grey of releasing "unofficial" APIs in our "official" releases. >> Does the OSGi alliance disallow the inclusion of these "unofficial" APIs? >> Effectively, option (2) is a hybrid approach, since we couldn't make modifications in the provisional API unless it were available in a public spec snapshot, so any modifications would have to be done in felix package namespace. Which sort of makes (2) the worst of both worlds. >> >> Well, if the snapshots are so outdated that it does not make sense to >> implement them, then we should not even try. In that case, just stick to (1). > > Sometimes it is not an issue of being out of date. If we want to implement a > feature for potential inclusion into an RFC, then we run into the same issue > if we add the feature to an existing OSGi API (whether it is provisional or > not). I think that the versioning policy that the OSGi Alliance uses leaves us little room here, so again we should probably go to (1). I mean, let's say that spec 1.6 is the latest stable release and there is a draft for 1.7 then there is no number in between that we could use to indicate we're past 1.6 but not yet at 1.7. >> I guess the other point would be for the OSGi Alliance to just develop new >> RFCs out in the open, but as long as they're not, it's probably safer to >> ignore them if it could cause problems otherwise. > > Well, we don't want to ignore them since we want to implement the provisional > specs and get experience with them. It is just difficult since our downstream > users have no way of knowing what is official OSGi API and what isn't if we > ship with provisional and/or modified org.osgi packages. We can always simply not release experimental code / provisional specs, keep them in an experimental branch if we want to still maintain an existing stable release. > Even following option (1), it's still a tricky balancing act, especially in > cases where we might actually provide the RI, such as Gogo or CM. But this is > more difficult for us since we release early and often as opposed to Eclipse > which releases yearly. As long as we release in our own namespace, I don't see the problem. Let's say we do an experimental release of CM. We would release it as a bundle exporting org.apache.felix.service.cm. The only "tricky" part is that consumer bundles would have to use the packages in our namespace, so it would probably mean they'd have to be written specifically for our implementation. But that's probably the best way to experiment safely anyway. Greetings, Marcel
Re: Handling of provisional OSGi API
On 9/17/10 12:54, Marcel Offermans wrote: On 17 Sep 2010, at 21:12 , Richard S. Hall wrote: On 9/17/10 12:11, Richard S. Hall wrote: On 9/17/10 11:36, Marcel Offermans wrote: On 17 Sep 2010, at 18:35 , Richard S. Hall wrote: 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). I prefer (1) too. I could see us combine (1) with (2), releasing implementations with both our own APIs which gives us the freedom to experiment with a new API whilst still "supporting what's provided by public releases of draft specs. However, this doesn't avoid the IP grey of releasing "unofficial" APIs in our "official" releases. Does the OSGi alliance disallow the inclusion of these "unofficial" APIs? Effectively, option (2) is a hybrid approach, since we couldn't make modifications in the provisional API unless it were available in a public spec snapshot, so any modifications would have to be done in felix package namespace. Which sort of makes (2) the worst of both worlds. Well, if the snapshots are so outdated that it does not make sense to implement them, then we should not even try. In that case, just stick to (1). Sometimes it is not an issue of being out of date. If we want to implement a feature for potential inclusion into an RFC, then we run into the same issue if we add the feature to an existing OSGi API (whether it is provisional or not). I guess the other point would be for the OSGi Alliance to just develop new RFCs out in the open, but as long as they're not, it's probably safer to ignore them if it could cause problems otherwise. Well, we don't want to ignore them since we want to implement the provisional specs and get experience with them. It is just difficult since our downstream users have no way of knowing what is official OSGi API and what isn't if we ship with provisional and/or modified org.osgi packages. Even following option (1), it's still a tricky balancing act, especially in cases where we might actually provide the RI, such as Gogo or CM. But this is more difficult for us since we release early and often as opposed to Eclipse which releases yearly. -> richard
Re: Handling of provisional OSGi API
On 17 Sep 2010, at 21:12 , Richard S. Hall wrote: > On 9/17/10 12:11, Richard S. Hall wrote: >> On 9/17/10 11:36, Marcel Offermans wrote: >>> On 17 Sep 2010, at 18:35 , Richard S. Hall wrote: >>> 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). >>> I prefer (1) too. >>> >>> I could see us combine (1) with (2), releasing implementations with both >>> our own APIs which gives us the freedom to experiment with a new API whilst >>> still "supporting what's provided by public releases of draft specs. >> >> However, this doesn't avoid the IP grey of releasing "unofficial" APIs in >> our "official" releases. Does the OSGi alliance disallow the inclusion of these "unofficial" APIs? >> Effectively, option (2) is a hybrid approach, since we couldn't make >> modifications in the provisional API unless it were available in a public >> spec snapshot, so any modifications would have to be done in felix package >> namespace. Which sort of makes (2) the worst of both worlds. Well, if the snapshots are so outdated that it does not make sense to implement them, then we should not even try. In that case, just stick to (1). I guess the other point would be for the OSGi Alliance to just develop new RFCs out in the open, but as long as they're not, it's probably safer to ignore them if it could cause problems otherwise. Greetings, Marcel
Re: Handling of provisional OSGi API
On 9/17/10 12:11, Richard S. Hall wrote: On 9/17/10 11:36, Marcel Offermans wrote: On 17 Sep 2010, at 18:35 , Richard S. Hall wrote: 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). I prefer (1) too. I could see us combine (1) with (2), releasing implementations with both our own APIs which gives us the freedom to experiment with a new API whilst still "supporting what's provided by public releases of draft specs. However, this doesn't avoid the IP grey of releasing "unofficial" APIs in our "official" releases. Effectively, option (2) is a hybrid approach, since we couldn't make modifications in the provisional API unless it were available in a public spec snapshot, so any modifications would have to be done in felix package namespace. Which sort of makes (2) the worst of both worlds. I should have been clearer, the two points I raise above are unrelated...they should have been in separate paragraphs. -> richard -> richard In the end, we are an open source project, so we should stick to what's available out in the open. Greetings, Marcel
Re: Handling of provisional OSGi API
On 9/17/10 11:36, Marcel Offermans wrote: On 17 Sep 2010, at 18:35 , Richard S. Hall wrote: 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). I prefer (1) too. I could see us combine (1) with (2), releasing implementations with both our own APIs which gives us the freedom to experiment with a new API whilst still "supporting what's provided by public releases of draft specs. However, this doesn't avoid the IP grey of releasing "unofficial" APIs in our "official" releases. Effectively, option (2) is a hybrid approach, since we couldn't make modifications in the provisional API unless it were available in a public spec snapshot, so any modifications would have to be done in felix package namespace. Which sort of makes (2) the worst of both worlds. -> richard In the end, we are an open source project, so we should stick to what's available out in the open. Greetings, Marcel
Re: Handling of provisional OSGi API
On 17 Sep 2010, at 18:35 , Richard S. Hall wrote: > 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). I prefer (1) too. I could see us combine (1) with (2), releasing implementations with both our own APIs which gives us the freedom to experiment with a new API whilst still "supporting what's provided by public releases of draft specs. In the end, we are an open source project, so we should stick to what's available out in the open. Greetings, Marcel
Handling of provisional OSGi API
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
