commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: [IO] Upcoming IO 2.4
Date Wed, 06 Jun 2012 14:16:01 GMT
Hi,

Am 06.06.2012 um 15:23 schrieb Gary Gregory:

> On Wed, Jun 6, 2012 at 8:57 AM, Felix Meschberger <fmeschbe@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 <fmeschbe@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: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message