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 <[email protected]> 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 >
