Am 2019-12-13 um 22:57 schrieb Oleg Kalnichevski:
On Fri, 2019-12-13 at 12:49 -0800, Ryan Schmitt wrote:
I would like to propose the following changes:
1. The `parent`, `core`, `client`, `website`, and `stylecheck` source
trees
shall be consolidated into a single Git repository for all of Apache
HttpComponents 5.
2. All artifacts contained in this repository shall be co-versioned
(i.e.
released in concert, with aligned version numbers [1]), similar to
the way
`httpcore5-reactive`, `httpcore5-h2`, and `httpcore5` are co-
versioned
within the `core` repository today.
Under this scheme, httpcore5 would still be a standalone product
subject to
the same compatibility constraints as today, but friction would be
significantly reduced for developers, as changes between `core` and
`client`--not breaking changes (at least not after GA), but additive
changes for new features, and bugfixes affecting both packages--could
be
coordinated in terms of development, code review, building, and
testing.
Currently `httpclient5` depends on the latest Maven release of
`httpcore5`,
which makes for a very awkward development experience: in order to
test
changes, I have to:
1. Make changes to core and install them locally as a SNAPSHOT
release
2. Change the client to depend on this SNAPSHOT release
3. Change the client codebase, sometimes extensively, to work with
this
SNAPSHOT release of core
4. Install the client SNAPSHOT locally
5. Change whatever I'm working on to consume the latest SNAPSHOT
releases
of both core and client
I think building (and versioning) core and client together would
drastically simplify this procedure, making it less error-prone, and
easier
to develop and review overarching changes to all of httpcomponents.
In the
long term, I also think it would simplify things for users to have a
single
set of versions for core and client, similar to the way Jackson
versions
are aligned [1].
Jackson does not use a mono repo. They have distinct repos (subprojects)
on GitHub.
The moving targets you have described will slow down when version 5 has
gone GA.
I understand it can be frustrating while core APIs are not stable
but core and client components tend to have different maturity cycles
and therefore having distinct release cycles for core and client
components is beneficial. In HC 4.x we can make fixes to core
components and release them fast while some client features are still
being worked on and are not ready for a release.
We might also have a reverse-proxy or a more feature rich server sub-
projects at some point. Coupling core with client would make it much
harder and would necessitate a separate core project again at that
point.
I agree with Oleg's views. All subprojects move at different speeds.
Parent and website and changed rarely, why force releases? So are core
and client logically decoupled.
Also consider the more modules you have in a reactor, the longer it
takes to build and test everything.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
