Hi, Am 06.06.2012 um 15:23 schrieb Gary Gregory:
> On Wed, Jun 6, 2012 at 8:57 AM, Felix Meschberger <fmesc...@adobe.com>wrote: > >> Hi, >> >> Am 06.06.2012 um 13:52 schrieb Gary Gregory: >> >>> On Wed, Jun 6, 2012 at 6:40 AM, Felix Meschberger <fmesc...@adobe.com >>> wrote: >>> >>>> Hi >>>> >>>> I am on the Felix and Sling projects where we use commons IO and are >>>> confronted with a OSGi semantic versioning issue with the Commons IO 2.x >>>> bundles. >>>> >>>> According to [1] Commons IO 2.0 is binary compatible with Commons IO >> 1.4. >>>> So I would assume all 2.x versions are binary compatible with 1.4. Am I >>>> right ? I hope so ;-) >>>> >>>> The problem comes with the package export which is set to be the package >>>> version of the library, hence 1.4 for the 1.4 release and 2.x for the >> 2.x >>>> releases. From the POV of OSGi semantic versioning this stipulates >> binary >>>> incompatiblity because of the change in the major version number part. >>>> >>>> Would you mind exporting the packages twice ? Once at version 1.5 >> (higher >>>> than the last 1.4 library release) and once at the actual library >> version >>>> (to not alienate original IO 2.0 clients) ? >>>> >>> >>> I hope to hear from others but here some my first impressions. >>> >>> It feels wrong to mark something with a version (1.5) that does not >>> exist... >> >> Point is, that 1.4 is out, 2.x has new classes/methods in a backwards and >> binary compatible way. So it is more than 1.4. >> >>> >>> It feels really weird to mark something with two version numbers. Is that >>> even legal in OSGi? >> >> Yes, AFAICT it is. >> >>> >>> How does that make sense? If a package is exported as 1.5 and 2.0 it does >>> not break and breaks BC at the same time. At least that's how I read your >>> definitions and the executive summary in >>> http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf. >> >> Right. An export of 2.0 stipulates an incompatible change. So in practice >> current consumers of 1.4 could use 2.0 but since the Export-Package has >> been updated to 2.0, they will not be wired because of their semantic >> import version of [1.4,2) indicating anything up to but not including 2.0.0. >> >> Consumers of the 2.0 library would, on the other hand, import [2.0,3) >> indicating at least 2.0 but not 3.0.0 or higher. If only 1.x would be >> exported, those consumers would be alienated when upgrading to 2.4. >> >> So having both versions would satisfy both. >> > > This sounds like an issue each Commons component will have to deal with. I > wonder if having a separate version number make sense just for OSGi > purposes. If you want to go the route of helping the OSGi consumers by providing bundles, I fear this is part of the deal ... But not all hope is lost. The Aries project has a maven plugin to help with validating the Export-Package version with respect to evolution from previous versions. I think most doc is available from the initial issue ARIES-757 [1] (there is no release yet, but this could certainly be solved). > This makes the whole pile more confusing:( Right, it is so and this is what I said on the other thread. But this comes as a favor to your consumers ;-) > We could make it less > painful by supporting that through the Commons parent POM but still... > > In IO's case, the JRE requirements have changed from 1.3 to 1.5 to 1.6 from > version to version. How does that affect OSGi headers WRT BC? JRE requirements are requirements of the bundle. This is not a (direct) problem of the consumer. The consumer just cares for its own requirements (o.a.c.io.* at version x.y). In OSGi-speak a bundle has requirements and capabilities. Requirements must be satisifed for the bundle to be resolvable and thus become active; examples of such requirements are Import-Package and required JVM level (Bundle-RequiredExecutionEnvironment in earlier OSGi releases). Capabilities are the things a bundle provides to consumers; examples of such capabilities are Export-Package but also a declaration of OSGi services provided and more (the latest OSGi core spec introduces a generic requirement/capability model). Regards Felix [1] https://issues.apache.org/jira/browse/ARIES-757 > > Gary > > >>> >>> >>>> Would you consider a bug/patch and include it in the release ? >>>> >>> >>> JIRAs and patches are always welcome and often help people see what is >>> being proposed. The proof is in the pudding as the saying goes :) >>> >>> If you have not already, please check the release notes for all versions >>> you care about in >>> >> https://svn.apache.org/repos/asf/commons/proper/io/trunk/RELEASE-NOTES.txtto >>> make sure the semantics are not OK as they are for OSGi purposes. >> >> Will do. >> >> Regards >> Felix >> >>> >>> Thank you! >>> Gary >>> >>> >>>> Thanks and Regards >>>> Felix >>>> >>>> [1] http://commons.apache.org/io/upgradeto2_0.html >>>> >>>> Am 05.06.2012 um 19:38 schrieb Gary Gregory: >>>> >>>>> A heads-up to the ML: >>>>> >>>>> Commit'em if you got'em! >>>>> >>>>> I'd like to release 2.4 soon. >>>>> >>>>> FYI: My interest is in picking up the UTF-32 fixes, so any additional >>>>> testing and code review is most welcome. >>>>> >>>>> -- >>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >>>>> Blog: http://garygregory.wordpress.com >>>>> Home: http://garygregory.com/ >>>>> Tweet! http://twitter.com/GaryGregory >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
