rschmitt commented on PR #679: URL: https://github.com/apache/httpcomponents-client/pull/679#issuecomment-3109449555
> I do not understand your take on making API changes, especially given there were no breaking changes in this very change-set. True, but today's deprecation is tomorrow's breaking change, since the goal of deprecation is always in principle to remove the deprecated API. > But we cannot stop making gradual API improvements simply because that entails some extra work to upgrade. Otherwise the project will stagnate and fail. In my dayjob, I'm responsible for maintaining the Apache client's integration with our main service framework, as well as the rollout of the Apache client itself company-wide, and a number of other open source libraries as well. I have the ability to rebuild an extremely large amount of code against the latest changes to a given library (including running all the unit tests), which means I eventually find and have to deal with every breaking change in every release. (This is why I've had so many [bug reports to Log4j2](https://github.com/apache/logging-log4j2/pulls?q=author%3Arschmitt+) recently.) So I have a very good sense of how difficult upgrades are at scale, and how limited the "breaking change budget" is for a widely-used library. I prefer to see this budget spent on things like bugfixes, which will often break people who are already broken and don't realize it. (Excessive bugwards compatibility can _really_ stagnate a project.) API reorganizations are okay as long as there's a (working) migration path, but I still think there needs to be a good reason to commit to the eventual removal of an API. Otherwise there's no end to the refactoring that you can do, and I've seen lots of frankly frivolous deprecations cause issues at scale. A good example is `File.exists?` being [removed from Ruby 3.2.0](https://www.reddit.com/r/ruby/comments/1196wti/psa_and_a_little_rant_fileexists_direxists/) when the trivial delegation to `File.exist?` could have been left in place indefinitely. Similarly, _major_ version bumps can be reasonable, but there has to be a really compelling reason to do them, and I don't think they should be done more than every ten years or so. I specifically think that [JEP 14](https://openjdk.org/jeps/14) is a terrible idea: Java libraries should not follow the latest LTS release of the platform, that's _way_ too much instability at the scale of the Java ecosystem, and we've done well so far with workarounds (like reflection) to make use of newer JDK features (like Unix domain sockets, or ALPN/TLSv1.3 before they got backported to JDK 8 in MR3). > I do not understand your aversion to the use of `IOException`. My concern was that `IOException` is needlessly specific in a public API, considering that widening this to `Exception` or `Throwable` is a breaking change. I tend to not assign a lot of meaning to specific exception types, because of the pervasive and often forced use of wrap-and-rethrow. -- 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: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
