Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
To: dev@commons.apache.org
From: =?UTF-8?B?SsO2cmc=?= Schaible <joerg.schaible@gmx.de>
Subject: OSGi Version at Package Level
Date: Wed, 07 Jun 2017 02:10:27 +0200
Lines: 29
Message-ID: <oh7g9d$4o5$1@blaine.gmane.org>
Reply-To: joerg.schaible@gmx.de
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
User-Agent: KNode/4.14.10
archived-at: Wed, 07 Jun 2017 00:10:39 -0000

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?

Cheers,
Jörg


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