It sounds like these changes aren't going to happen, but I'm going to press the point anyway because I think this is important.
> I am not sure I can agree with that. Usually one should care about the > top level library such as HttpClient or HttpAsyncClient only. One needs > to manually override their HttpCore dependency only in case of some > severe bug in core components. HttpCore includes both :httpcore5-h2 and :httpcore5-reactive, which are brand new, highly complex components that are much less stable than :httpcore5 (which is not that stable in the first place). By your own admission, I could have written my entire SDK integration using just these three components. That's a guarantee that HttpCore will *not* be a mature, slow-moving product any time soon, and that users will need to explicitly track both versions if we persist in this scheme. Let's not kid ourselves: HttpCore is going to be plagued with serious bugs for years, and we will regularly put out unusably defective releases. The complexity of HTTP/2 is all but unmanageable. I've seen it myself working with Netty, which *still* hasn't stabilized its high-level HTTP/2 API after all this time and effort. > Parent and website and changed rarely, why force releases? So are core > and client logically decoupled. On reviewing the repositories, I agree with you about parent and website (and stylecheck), since these repositories don't produce Maven artifacts for public consumption. However, I see the version decoupling of core and client as purely a source of friction for everyone, adding no value whatsoever. You object to the idea of "forcing releases" of other components. Why? What resource exactly do we manage to conserve by releasing three jar files at a time, instead of six? The contradiction, by the way, is quite glaring here: why are :httpcore5, :httpcore5-h2, and :httpcore5-reactive unified and version aligned with each other, while HttpCore and HttpClient are decoupled? It makes no sense. > Also consider the more modules you have in a reactor, the longer it > takes to build and test everything. First of all, even this claim is not true if you consider how much faster Gradle could build everything in a single repository, by parallelizing across all modules. More importantly, the time it takes to *iterate* on coordinated changes between Core and Client is literally orders of magnitude longer because they are developed totally separately. > The moving targets you have described will slow down when version 5 has > gone GA. Right now, to debug my sporadically failing integration tests in HttpClient, I want to add debug logging to various places in HttpCore, and add other types of debugging code as well. Every time I change the debugging code, I have to locally simulate *an entire release cycle* of HttpCore, instead of just making all of these changes through my IDE in a single workspace.
