On Tue, Jun 6, 2017 at 5:10 PM, Jörg Schaible <joerg.schai...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
