How does this relate, if at all, to the COMPATIBLE_API_VERSIONS constant defined in ProviderUtil.java? We use that to ensure the API only binds with a compatible implementation of the API.
Ralph > On Nov 13, 2023, at 1:29 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > 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
