On Sat, Apr 4, 2026 at 10:50 AM Oleg Kalnichevski <[email protected]> wrote:
> > I personally do not see how throwing everything into a single project > with a single release cycle would make any difference here. The only > person presently hurt by having to manage separate release cycles for > core and client is me, as their release manager. The separation of core > and client has many benefits. Why would we want to throw it all away? > Just to spare an extra trouble having to import two modules into a > single IntelliJ project? > > [...] > > How would a single repository make any difference with regards internal > APIs? @Internal is a just a way of marking classes with public > visibility as having different contract when they cannot be made package > private. > > I really have a problem understanding your motives here. > > Oleg The motivation is to be able to make "breaking changes" to the ~96 `@Internal` APIs in HttpCore5. Here's a recent example of the problem I'm trying to solve: https://github.com/apache/httpcomponents-client/commit/9c83a8e43fb82467351a6d16b1ae78e0f6320873 Currently, HttpCore has to be backward compatible with prior releases of HttpClient, and HttpClient has to be forward compatible with newer versions of HttpCore. What I'm suggesting is that we can maintain the same logical separation of HttpCore and HttpClient we have today, but simplify the compatibility contract between the two by always building and releasing the two projects together. This is similar to what we already do with e.g. `httpcore5` and `httpcore5-h2`: the two projects are logically separate and have distinct Maven coordinates, but (as far as I know) we don't have to support consumers mixing different versions of the two modules, and we can make coordinated changes that span both modules. We could even do this while maintaining the current repository structure. We don't _have_ to consolidate the repositories in order to consolidate the release trains. Jackson is an example of this; the project is spread out through several repositories: https://github.com/FasterXML But maintains a single release train: https://github.com/FasterXML/jackson-bom/blob/2.21/pom.xml#L64-L70 The only _additional_ advantage to consolidating the repositories is that it would be easier to make coordinated changes between HttpCore and HttpClient, since (as far as I know) GitHub does not support pull requests spanning multiple git repositories. If we consolidated the repositories and built both projects in a single Maven reactor, then changes that spanned HttpCore and HttpClient could be made atomically, rather than in two phases as we currently do. You can also generalize this consolidation to include httpcomponents-parent, -website, -stylecheck etc, which would have additional benefits like simplifying build logic updates, incorporating website updates into feature PRs, etc. I'm putting forth this suggestion because I believe it's a straightforward simplification _of the existing separation_ between core and client. There may be downsides or issues here that I'm not aware of.
