The version number only changes when we intentionally change the API so that it
would cause failures with an older implementation. For example, I believe the
last time it changed was when we introduced ServiceLoader to locate the
implementation.
In 3.x the constant is set to 3.0.0 as the Log4j
It’s similar to the compatible API versions, but the BND equivalent here would
be the highest package version of all the packages in log4j-api (since the
packages don’t get split out from the modules in practice).
—
Matt Sicker
> On Nov 13, 2023, at 16:02, Piotr P. Karwasz wrote:
>
> Hi Ralph,
Hi Ralph,
On Mon, 13 Nov 2023 at 22:18, Ralph Goers wrote:
>
> 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.
It is certainly related, although in p
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 wrote:
>
> Hi all,
>
> As you probably noticed, a
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 in
