Hi Ralph, On 14.11.2024 19:46, Ralph Goers 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.
That version hasn't been incremented since `2.6.0`, but I believe that we could refresh that mechanism to check for compatibility between Log4j API and Log4j Core. IMHO that field should store the **real** minor version of Log4j API, i.e. the version when the last public/protected method or class was added (`internal` packages excluded).
If we implement it in `2.25.0`, it would mean that Log4j Core 2.25.x, 2.26.x, etc. will be guaranteed to work with Log4j API 2.25.x until we bump the "internal" Log4j API number to `2.26.0`. Of course it would be very useful if the "internal" Log4j API version was equal to the "external" one. Maybe we should migrate Log4j API to a separate lifecycle for the 2.25.x release?
Piotr
