kinow commented on pull request #299: URL: https://github.com/apache/commons-io/pull/299#issuecomment-962250111
> Hi @kinow , thank you for taking the time to review this pull request. I have a question for you about the deprecated / removed methods. Since CharSequence is the interface that is implemented by the types that the (removed in the PR) methods accepted as first parameter (String, StringBuffer), is it still necessary to retain those overloaded methods, since the existing methods that accept CharSequence are using the same logic? Hi @wodencafe the issue is backward compatibility. If we remove public methods (or modify the code in a way that breaks binary backward compatibility [^1][^2] or sometimes behavioral backward compatibility [^3][^4]) we need to think about the users of the API first. We could have users of Commons IO that are using those methods in their code. So if we remove these methods, users would expect a [major](https://semver.org/) version release so they are aware that there are API changes. Releasing major versions can be inconvenient to users too, as even those that were not affected will have to either review the changes or simply upgrade their code. For that reason, we accumulate changes that require major releases by deprecating unwanted code whenever possible. I think your change makes sense, if users can rely on the parent type for String/StringBuffer. That would be less code to maintain I guess. We just may need to delay reviewing and merging it until we are ready for a major release :+1: Hope that makes sense. Thanks! Bruno [^1]: https://www.oracle.com/java/technologies/compatibility.html#binary [^2]: https://en.wikipedia.org/wiki/Binary-code_compatibility [^3]: https://www.oracle.com/java/technologies/compatibility.html#behavioral [^4]: https://docs.microsoft.com/en-us/dotnet/core/compatibility/categories#behavioral-change -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
