ppkarwasz commented on PR #3372: URL: https://github.com/apache/logging-log4j2/pull/3372#issuecomment-2984789617
Hi @norrisjeremy, > To answer your question about the impact: we deliberately run compiler warnings & deprecations set to errors for our internal apps, so that they immediately cause a compilation failure, in order for our team to notice and deal with API deprecations immediately and avoid having them pile up over time. That’s a great policy—seriously! 👏 It’s not something we see often; more typically, teams tend to tolerate deprecated methods and configuration properties until something breaks. Because of that, we don't usually factor the impact of deprecations into our decision-making. So, thank you for calling attention to your approach—it’s helpful context for us going forward. > And then when trying to load up the latest Javadocs, noticed that they had not yet been published on the website. (And in fact updated Javadocs are still not published, as all the pages linked [here](https://logging.apache.org/log4j/2.x/javadoc.html) lead to 404 page not found errors...) That was ironically caused by a recent change in the Maven Javadoc Plugin (apache/maven-javadoc-plugin#1163). While it improved consistency, it also broke our site build :wink:. This has now been fixed—thanks for bringing it to our attention! > On top of this, this is the second time in past year that this API method has been touched. In the 2.24.0 release, the original `withtFilter()` was marked as deprecated in lieu of the new `withFilter()` method (see #788). Yes, good catch. That change was made in 21ad7be2f7f08118cc5022c8e6ce2e4555b008d4, back when we still allowed Commit-then-Review for “trivial” changes. That likely contributed to us forgetting about the "review" part of the process. We've since moved to a strict Review-then-Commit policy for all changes, which should help avoid similar oversights in the future. > So all told, this is just frustrating: it results in lost time & productivity for what is amounting to whack-a-mole operation, chasing the whims of upstream library developers: deprecating and changing withers to setters in a Builder class just doesn't seem to offer tangible benefit to any existing users. Totally understandable. This change reflects an effort to standardize the API and address inconsistencies that date back to the early development of Log4j 2. That said, I agree that the change has only an aesthetic effect. I don't want to leave things in the middle, so I’ve scheduled #3750 for the `2.26.0` milestone, but we will deprecate all remaining "withers" in a single go. As mentioned, we assume most users rely on configuration files—which are unaffected by these changes. But for those constructing configurations programmatically, we recommend using [`ConfigurationBuilder`](https://logging.apache.org/log4j/2.x/manual/customconfig.html#ConfigurationBuilder). It's a more stable and future-proof approach, unlike directly using plugin builders, which can be more volatile. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
