OkHttp 4.9.0 version bump

[snodnipper]

Note: removed slashes from method name to avoid 'illegal method name' errors, see: https://issues.apache.org/jira/browse/GROOVY-8795

See #53

[oscerd]

As in the past the version should be aligned to what we use in kubernetes-client, so 3.12.12
https://github.com/fabric8io/kubernetes-client/blob/master/pom.xml#L83

[rohanKanojia]

But I'm observing that there are people who use this library directly. Maybe we can cut a separate 4.x release for them?

[oscerd]

I would make master point to okhttp client 4.x and create a branch based on client 3.x. Maybe we can use the 0.1.x version for mockwebserver based on 3.x and point to 0.2.x-snapshot for 4.x

[snodnipper]

@oscerd is there an action on me or is this something that you can handle as you'd like? Thanks.

[rohanKanojia]

I think we need to manage it on our side. Thanks for your contribution.

[oscerd]

Yes, I think we can manage everything on our side. I think we can branch from actual master to 0.1.x, then merge this PR and change to 0.2.0-SNAPSHOT

[jorsol]

But I'm observing that there are people who use this library directly. Maybe we can cut a separate 4.x release for them?

Does this mean having two versions of the same release just with different dependencies?

Some people might not want to use okhttp 4.x (for the kotlin dep), so I'm not really sure what is this trying to fix from the PR point of view, if okhttp 4.x is fully backwards compatible with okhttp 3.x by just changing the version property, the way to handle this is to simply exclude the okhttp 3.x dependency and include the 4.x where is needed, more work for the end user, but it's more aligned with kubernetes-client dependencies.

The ideal (and more complex) way to handle this is to have a facade of different transports, this way one could switch from different dependencies as needed, somewhat like: https://github.com/docker-java/docker-java/blob/master/docs/transports.md but this is a completely different story.

[testifyqa]

Hi there, any updates on this? Would love to get an up-to-date version with the latest OkHttp v4, rather than have to rely on forking and updating ourselves etc

[manusa]

Hi there, any updates on this? Would love to get an up-to-date version with the latest OkHttp v4, rather than have to rely on forking and updating ourselves etc

Since Fabric8 Kubernetes Client is tightly coupled to the MockServer we are not able to update it unless we update the downstream version too. (fabric8io/kubernetes-client#2632)

On version 6.0.0 of the client we are completely decoupling the HttpClient dependency and we'll be able to provide several implementations. Once it is released we should be able to update the MockServer to OkHttp 4, or maybe even completely remove this dependency. (fabric8io/kubernetes-client#2764)

[manusa]

This project is now being moved to a module in the Fabric8 Kubernetes Client project.

Any upgrade to the OkHttp client version will be done there.

#56