I agree with Gary. That is a good reason to release every module with every release, to save people the headache of figuring out compatible versions.
On Thu, Nov 14, 2024 at 9:41 PM Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > > > > >
