Hi Jeff,
On Fri, 15 Mar 2024 at 07:50, <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
