On Mon, Apr 6, 2026, 13:33 Ryan Schmitt <[email protected]> wrote: > 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. >
I really like the idea of a monorepo. We can start with core and client and then bring in the other ancillary(ies?) repositories. I'm never super confident that any other combination than a client release plus that exact version of core the client POM refers to will work 100% flawlessly. Gary
