TomerAberbach commented on PR #619: URL: https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2731261012
Hey folks, I'm a software engineer at [Stainless](https://stainless.com). We generate Java/Kotlin SDKs and they all use `MultipartEntityBuilder` from this library. I was just made aware of this change. I don't agree with a fixed boundary being the default behavior, but putting that aside, does this PR change the default behavior in a non-major version bump? It seems like a clear breaking change to me. If this will not be associated with a major version bump, then we're going to have a serious problem. The SDKs will be stuck between the following two choices: 1. Bump `httpcomponents-client` to the new version so that I can call `withRandomBoundary()` to guarantee a valid boundary - The problem with this is that [Maven dependency mediation](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html) may still cause an older version to be chosen (e.g. if the end-user of the SDK is using another version of `httpcomponents-client` directly or indirectly). In that case, the SDK will began crashing with `NoSuchMethodError` because `withRandomBoundary()` will not exist in that version. So really, I can't upgrade to this new version until it's been out for quite a while, unless I want to force all end-users to upgrade too, which is arguably a breaking change to my SDK. 2. Don't bump `httpcomponents-client` to the latest version - The problem with this is that the behavior is changing in this new version and again, because of Maven dependency mediation, I have no control over which version my end-user ends up using. But because I didn't bump the version, I can't call `withRandomBoundary()`. So I can't guarantee the particular behavior I want for the SDKs. Technically I could use reflection to look up at runtime whether `withRandomBoundary()` exists, and call it if it does, but I would really like to avoid those kinds of hacks. --- So with all that being said, if you're not going to revert this PR, can you at least release this as a major version bump? I think it would be the responsible thing to do to set expectations around which versions of this library are backwards compatible with each other. -- 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
