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. > > >> 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
