sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konrad Windszus <konra...@gmx.de>
Subject Re: bnd baselining and development versions
Date Fri, 20 Sep 2019 09:34:54 GMT
That would officially violate https://www.osgi.org/developer/white-papers/semantic-versioning/bundles-and-fragments/
<https://www.osgi.org/developer/white-papers/semantic-versioning/bundles-and-fragments/>
and the warning come from bnd itself.
https://github.com/bndtools/bnd/blob/abdf289ce7599d1595a29ec546774d56eb824f99/biz.aQute.bndlib/src/aQute/bnd/differ/Baseline.java#L297
<https://github.com/bndtools/bnd/blob/abdf289ce7599d1595a29ec546774d56eb824f99/biz.aQute.bndlib/src/aQute/bnd/differ/Baseline.java#L297>

I think the only permanent solution is either
a) adjust the bundle version accordingly (and rather get rid of odd/even release version numbers)
b) adjust bnd to support an instruction which allows to skip the bundle version check

Thanks
Konrad


> On 20. Sep 2019, at 11:23, Robert Munteanu <rombert@apache.org> wrote:
> 
> Hi,
> 
> After locally updating a module to use the latest parent pom, with the
> bnd Maven tooling, I get a complaint with bnd that the version is too
> low.
> 
> The bundle version change (1.2.6 to 1.2.7) is too low, the new version
> must be at least 1.3.0
> 
> That is fine, and I agree with it. However, it goes against our
> practice of using odd/even versioning numbers and changing the version
> on release.
> 
> I've disabled the baseline check for that module for now, but it would
> be good to have a more permanent solution.
> 
> Thanks,
> Robert
> 


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