commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: OSGi Version at Package Level
Date Wed, 07 Jun 2017 10:34:09 GMT
On Wed, 7 Jun 2017 10:54:54 +0100, sebb wrote:
> On 7 June 2017 at 09:02, Bertrand Delacretaz <bdelacretaz@apache.org> 
> wrote:
>> On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg <ebourg@apache.org> 
>> wrote:
>>> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>>>... Implementing semantic versioning at the java package level as 
>>>> opposed
>>>> to bundle level.
>>>
>>> That's the theory, I'm actually curious to see what real issue it 
>>> solves
>>> with commons-compress....
>>
>> I agree that what I explained is "the theory" which is very valid in
>> complex systems fully based on OSGi, avoiding problems if for 
>> example
>> an API package is provided by multiple bundles.
>>
>> But maybe it doesn't make sense for commons-compress, I don't know
>> that code well enough to comment.
>
> I doubt package-level versions make sense for (m)any Commons 
> components.
> AFAIK most components are only usable and released as a whole.

It would have made sense in a certain component that is so big that
many parts of it did not fundamentally change between two releases,
yet where bumped into a different top-level package because other
parts required an incompatible release.

For a single "real" component (small scope), it is not necessary,
almost by definition.

For a bunch of utilities, e.g. (maven) modules, that can evolve
independently or at different paces, it seems like a neat idea.
[As was explained by Stian some time ago (when I had proposed to
allow module versions, it is a political decision, not a technical
one.]


Regards,
Gilles


> It might make sense for VFS I suppose, if that wants to release
> implementations separately.
>
>> -Bertrand
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message