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]. >
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. Unless we decide we only develop HttpClient and nothing else, which is fine by me as long as this is what we all want. Oleg > It's worth pointing out that these repositories can easily be > consolidated > in such a way that their histories will all be retained, so that > operations > like `git blame` and `git log` will continue to give useful results. > It's > also interesting to note that the OpenJDK project recently > consolidated > their repository tree into a single Mercurial repository [2], with > the next > goal being migration from Mercurial to Git [3]. > > If the other committers are open to considering this idea, I'd be > glad to > put together a proof-of-concept. > > [1] > https://docs.gradle.org/current/userguide/dependency_version_alignment.html > [2] https://openjdk.java.net/jeps/296 > [3] https://openjdk.java.net/jeps/357 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
