I don't even want to try and explain that... it sounds backwards. I'll just keep everything nice and simple in my explanations to people: match is nice.
Gary On Thu, Nov 14, 2024, 1:47 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Log4j core has a version compatibility comparison just for this reason. If > core is updated to require some new feature in the API then the version it > checks for needs to be updated and Log4j-API needs to update its version > when it adds new features. > > Ralph > > > On Nov 14, 2024, at 3: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 > > > >
