Hi Jeff, On Fri, 15 Mar 2024 at 07:50, <jeffrey.tho...@t-systems.com> wrote: > Yes the Javadoc did a fine job of explaining the reason for the change and I > understood it, but there are so many side-effects from deprecating those > APIs. My question was more of a "why do this in advance?" 😆
The deprecation was introduced as a requirement of semantic versioning: "Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API."[1] However in January this year (cf. [2]) we decided that we will not release a Log4j API 3.x version in the foreseeable future. We will only release a major version of our logging backend Log4j Core. I guess this means we can remove the @Deprecated annotation. Personally it bothers me too to introduce all those `@SuppressWarnings` annotations. > It took us unfortunately a long time to get to 2.x and I am pretty sure we > won't be jumping on the 3.0 version at release, so the idea of dealing with > those deprecations for another 1-2 years is sobering. 😪 While we chose the same Java baseline as Spring Boot 3.x (Java 17), Log4j Core 3.x will be easier to deploy, since it will just require the replacement of a runtime dependency. Piotr [1] https://semver.org/#how-should-i-handle-deprecating-functionality [2] https://lists.apache.org/thread/p2lgr3xtt9hq77j7r67r8x1tc1z7kbol --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org