I think you keep it simple: versions must match. Versions that are unmatched are not supported. That's what I tell people at work and anyone who asks. Simple ;-)
Gary On Thu, Nov 14, 2024, 5:25 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > Hi all, > > We usually recommend users to have a perfect version alignment between > `log4j-api` and `log4j-core`. As reported by Dominik in [1], users of > Apache POI and other libraries that use Log4j API, often end up with > mismatched versions. The reason behind this is simple: `log4j-api` is a > **transitive** dependency for most users, while `log4j-core` is a > **direct** runtime dependency. If an application depends on Apache POI > and Log4j Core, the resolved version of `log4j-api` is managed by > Maven's conflict resolution. > > Should we support and test Log4j with mismatched version of `log4j-api` > and `log4j-core`? > > The general expectation for an API/implementation version compatibility > is that implementation 2.<n>.x is compatible with API 2.<m>.x whenever > <n> is at least <m>. For example an application that uses Servlet API > 2.0, should be compatible with a Servlet API 2.4 server (actually it is > compatible with a Servlet API 4.0 server too). Should we provide a > similar compatibility guarantee for Log4j API and Log4j Core? > > Of course the nice compatibility properties of Servlet API come from the > fact that even if an application is **compiled** using Servlet API 2.0, > at runtime the server will load the Servlet API version appropriate for > the server. A Servlet API server will accept applications written using > any previous version of the Servlet API as long as the Servlet API > itself has no breaking changes (like the `javax` to `jakarta` migration > ;-)). > > Logging APIs do not profit from the same mechanism and semantically > MINOR changes in the API (like the addition of a new > `LoggingEventBuilder` interface) break the compatibility of a logging > implementation with previous releases of the matching logging API. This > is for example the main reason why the SLF4J2-to-Log4j API bridge > (`log4j-slf4j2-impl`) does not work with SLF4J 1.7.x. If we want Log4j > Core `2.25.0` to work with Log4j API `2.24.0` we: > > * Can not use in Log4j Core any new utility method that appears in Log4j > API `2.25.0`. > > * The compatibility will be broken if we add a new type to the public > Log4j API (unlikely). > > I think I can live with these restrictions. If we really feel that we > need to share some utility methods between the `log4j-core`, > `log4j-to-jul` and `log4j-to-slf4j` implementations, we can create a > `log4j-kit` artifact as we have done in Log4j Core 3.x. > > What do you think? Can we guarantee that in the near future new versions > of Log4j Core will be compatible with Log4j API 2.24.x? > > Piotr > > [1] https://github.com/apache/logging-log4j2/issues/3196 > >
