Hi all, As you probably noticed, all our packages (at least the exported ones) are annotated with the OSGi annotation `@Version`. This might result in failures from the `bnd-baseline-maven-plugin` if you make changes in the public API without incrementing the version annotation.
Since BND only indicates the minimal version increment, we can adopt many different conventions on package versioning. For example OSGi itself increments the packages by the minimal amount (so OSGi 8.0 contains version 1.10 of OSGi Framework API). Personally I would find such a convention confusing since OSGi is not our main market. If we have a package versioned 2.3.4 and BND asks as to upgrade the version I would propose: * if BND classifies the change as `MICRO` to use 2.3.5, * if BND classifies the change as `MINOR` to use the next Log4j minor release number (e.g. 2.22.0); such a change can not be included in a patch release, * if BND classifies the change as `MAJOR`, either we publish the change only in the `main` branch or we fix it so that it is not a breaking change. Remark that some changes that can not possibly break any existing code, might be classified by BND as `MAJOR`: e.g. removing `protected` methods from `final` classes is such a limitation. In such cases we can override BND's decision using the `diffpackages` configuration of the plugin: https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-baseline-maven-plugin#diffpackages Piotr
