Hi Gary,
On 28.11.2024 23:06, Piotr P. Karwasz wrote:
On 28.11.2024 16:00, Gary Gregory wrote:
This is beyond confusing and a new kind of "soft" jar hell IMO.
I read this twice and I have no idea how a user would make sense of this.
Log4j 2.x should be all in sync, all jars should be released with each
version and match. Period. IMO.
From the user's perspective, what I am proposing means:
- If we split Log4j API to a separate release lifecycle then Log4j Core
2.x will depend on Log4j API 2.25.y for a very long time.
- If we don't split Log4j API to a separate release lifecycle then Log4j
Core 2.x.y will depend on Log4j API 2.x.y, but Log4j API will be
effectively frozen with no new methods in the "private" packages. If we
add a method that users can actually call, then sure, we will break
compatibility with older Log4j Core versions. This however has not
happened in a very long time.
Regardless of the strategy we choose, there is a simple way to find out
which Log4j API version is required by Log4j Core: it's the version in
the POM file of Log4j Core. To prevent Maven's conflict resolution to
choose the version of Log4j API from dependency `foo` instead of
`log4j-core`, we have Log4j BOM.
If a user reports an incompatibility between Log4j API and Log4j Core,
the right recommendation IMHO is not "Use aligned versions", but "Use
`log4j-bom`". This has also the advantage of being a universal
recommendation: it works for both Log4j Core 2 and Log4j Core 3.
