On 06.04.2026 19:32, Ryan Schmitt 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
What this particular incident vividly illustrates is that the last minor
release of core was rushed. I thought that was quite clear.
The core should have a much, much longer testing and stabilization cycle
than client and a more conservative release cadence. Not less.
I fail to see how throwing all components into the same monorepo
(physical or otherwise) with a single release cycle would make breaking
the API contract less likely. The only thing this will surely accomplish
is filling the artifact repository with more binary artifacts.
We can revisit this subject in the course of 6.x development whenever
that may happen but I doubt my opinion on the subject is going to change.
Oleg
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
