Hi Julian, Thank you for starting this discussion.
In Apache Log4j we've been using OSGi semantic versioning since version 2.21.0, which is why the Log4j API package (o.a.logging.log4j) has still version 2.20.2. We use the BND plugins directly, since at that time Felix was releasing the maven-bundle-plugin very sporadically. >From my experience it does introduce some churn, especially for contributors that unnecessarily introduce new public methods, but the is not necessarily bad, since the maintainers can easily spot them from a build failure and ask the contributor to make the method private. We created a small guide for contributors, so bumping a package version is not a problem any more: https://logging.apache.org/logging-parent/troubleshooting.html#bnd-baseline What is still confusing, even for maintainers, is bumping the version by the right amount or reverting the bump after a change was rolled back or cherry-picked to an older branch. We do *not* always follow the *minimal* version bumps: when we introduce a new public API we bump the version of the package to the version of the artifact, *not* the minimum required. This spares us the headache of wondering, whether version 4.21.0 of the package was introduced in version 4.45.0 or 4.46.0 of the artifact. When we introduced this in Log4j, there wasn't any tooling that protected us from *unnecessary* version bumps. On 1.10.2026 10:58, Julian Reschke wrote: > You'll get warnings like > > [WARNING] org.apache.commons.collections4.bag: Excessive version > increase; detected 4.6.1, suggested 4.6.0 > > because the export version needlessly changed. I'll check this out, since it might be interesting, although, as I mentioned above for minor version bumps I find bumping the version to the version of the artifact less confusing. Piotr [1] https://logging.apache.org/log4j/2.x/release-notes.html#release-notes-2-21-0 [2] https://logging.apache.org/logging-parent/troubleshooting.html#bnd-baseline --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
