Wrong import-package version ranges

[kwin]

Despite using version ranges in Gradle (https://github.com/mizosoft/methanol/pull/168) the generated version range from bnd takes the newest available version as lower bound, e.g. for methanol-jackson-1.9.0-SNAPSHOT.jar/META-INF/MANIFEST.MF:

...
Import-Package: com.fasterxml.jackson.core;version="[2.20,3)",com.fast
 erxml.jackson.databind;version="[2.20,3)",com.fasterxml.jackson.datab
 ind.json;version="[2.20,3)",com.github.mizosoft.methanol;version="[1.
 9,2)",com.github.mizosoft.methanol.adapter;version="[1.9,2)",java.io,
 java.lang,java.lang.invoke,java.lang.reflect,java.net.http,java.nio.c
 harset,java.util,java.util.function

It is supposed to have the lower bound 2.10.0 instead, but rather the newest version is used as lower bound: https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-core/versions.

Usually for bnd to generate correct boundaries you depend at compile time on the lowest version. Version ranges in Gradle are resolved before compiling and executing the bnd plugin (therefore won't help). Also I am a big friend of reproducible builds, therefore I would rather tend to not give version ranges to Gradle but deliberately update when necessary.

[kwin]

Compare also with https://docs.osgi.org/whitepaper/semantic-versioning/060-importer-policy.html

It is a common misconception that code should be updated when newer versions of libraries it depends on become available. Not only would this increase the chores of maintaining versions, it easily causes a continuous update cycle in deployment. Any change should change the version of the corresponding package, which requires an update of all the dependencies, which could trigger more changes. Systems designed that way become very brittle very quickly.