commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: OSGi Version at Package Level
Date Wed, 07 Jun 2017 00:18:51 GMT
On Tue, Jun 6, 2017 at 5:10 PM, Jörg Schaible <joerg.schaible@gmx.de> wrote:

> Hi,
>
> maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component.
>
> Actually I can understand the reasoning from a logical point if view, but
> it
> fails for me completely from the practical side. Do we really want
> different
> versions inside a single component? Can we even guarantee binary
> compatibility to such an extent? Do we want such a micro-management for
> each
> release?
>
> IMHO it does not make sense, our release process is enervating enough.
> Until
> now we provide one version for each release that is also valid for OSGi. I
> have not too much experience with OSGi myself, but when I look into the
> Eclipse ecosystem then I can see that a complete bunch of plugins is
> released together as one version - I am not aware that they do such package
> based version management. And - AFACIS - it is also possible to declare
> valid ranges for OSGi dependencies. And we ensure with our release policy
> for major versions (new package name) that no dependency can upgraded by
> pure chance to a major incompatible version.
>
> I won't put a veto on the commit of this PR, but actually I am not
> interesting in supporting such a scenario for our components.
>
> Your opinions?
>

It sounds like a maintenance nightmare.

Is there at least a Maven plugin to help like Clirr and japicmp, but for
OSGi?

Gary


>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message