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. Gary On Thu, Nov 28, 2024, 9:52 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > 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 > >
