[INITIATIVE] Fabric8 Kubernetes Client 7.0.0

[manusa]

Description

Placeholder issue for activities related to the v7 major release.

Tasks

• [EPIC] Model Generation using OpenAPI #6130
• [EPIC] MockWebServer based on Vert.x #5719
• [EPIC] Refactor Config #6516
• [EPIC] Remove deprecations #6602
• Set Java baseline to 11 #6081
  • chore(deps): bump sundrio.version from 0.103.1 to 0.200.0 #5965
  • chore(deps): bump com.marcnuri.plugins:gradle-api-maven-plugin from 0.0.5 to 0.0.6 #6035
  • chore(deps): bump com.samskivert:jmustache from 1.15 to 1.16 #6155
• Consider Migrating deprecated Felix Annotations to OSGi component Annotations #4445
• Readiness timeout (withReadyWaitTimeout) defaults to 0 instead of 5 (opt-in) #6140
• Move to use okhttp4 due to a bug on IPV6 based cluster #2632
• Switch default HTTP client from OkHttp to Vert.x #6470
• Rename SettableBeanPropertyDelegate to SettableBeanPropertyDelegating #6361
• CRD Generator
  • CRD-Generator: Change format in @PrinterColum to enum #6455
    See if this should go in since this is breaking change
• Release Fabric8 Kubernetes Client 7.0.0 #6034

[jorsol]

Just one small comment: Bump Java requirement to at least 11, we are in 2024, Java 8 was released 10 years ago, and there are 3 LTS released since Java 8 (11, 17, and 21), so there is no point in supporting Java 8 anymore (unless there is some kind of paid support 😉).

A major version release like 7.0.0 🏷️ is a perfect time to do this kind of change.

I would be more aggressive and bump to Java 17 🚀 , but that is just my personal preference.

[manusa]

Just one small comment: Bump Java requirement to at least 11, we are in 2024, Java 8 was released 10 years ago, and there are 3 LTS released since Java 8 (11, 17, and 21), so there is no point in supporting Java 8 anymore (unless there is some kind of paid support 😉).

Hi Jorge,
Sorry, this issue is still under construction. You can check a full list of features and changes for 7.0.0 at https://github.com/marcnuri-work/fabric8io-kubernetes-client-issues-5778
(Java 11 as baseline is one of them). If you feel there's anything else missing or were expecting anything else for this major version, please say so.

That said, I wouldn't fully agree with you regarding your statement and this project (and for other libraries in general). It's precisely this "there is some kind of paid support" involved in some of the downstream usage of this project and other libraries that make/force these kind of projects the last to update their Java baseline. Apparently Spring 5 (Boot 2) paid support can be at least extended to 2025 🤦.

The motivation in this case is that is not sustainable any more to keep up with Java 8 (at least not worth the effort). However, this means that we'll probably get an increased amount of requests for patch releases for version 6 (which will be the last one with Java 8 support). I do hope I'm wrong here and that this is not the case but only time will tell.

[jorsol]

That said, I wouldn't fully agree with you regarding your statement and this project (and for other libraries in general). It's precisely this "there is some kind of paid support" involved in some of the downstream usage of this project and other libraries that make/force these kind of projects the last to update their Java baseline. Apparently Spring 5 (Boot 2) paid support can be at least extended to 2025 🤦.

Well, I didn't explain myself correctly, and haven't mentioned downstream usage, I was referring to paid support to you (or the fabric8 team) not to paid support to "other" projects 😉, and even then, the commercial support should be just for the 6.x branch of KC... the 7.x branch should set the baseline to at least Java 11 without a doubt.

I fully agree that this project (and for other libraries in general), shouldn't be tied to other projects (especially if those other projects are in commercial support), Oracle will have extended support for Java 8 until 31 Dec 2030 (some vendors even longer than that 🤯), it doesn't make any sense that libraries get stuck just because of that.

The motivation in this case is that is not sustainable any more to keep up with Java 8 (at least not worth the effort). However, this means that we'll probably get an increased amount of requests for patch releases for version 6 (which will be the last one with Java 8 support). I do hope I'm wrong here and that this is not the case but only time will tell.

As mentioned, version 6.x should enter a kind of paid support maintenance, unless there is a critical security issue, there is no point in maintaining older versions, if someone requests for instance support for a newer version of K8s in the 6.x branch, that should be paid support.

I do know that this kind of project makes it hard to provide commercial support, so, in case that is not possible, just provide a best-effort (community-driven) patch release for version 6.

Hope I have cleared the misunderstanding. 😅

[manusa]

the commercial best-effort support should be just for the 6.x branch of KC... the 7.x branch should set the baseline to at least Java 11 without a doubt.

Just in case it's not clear, this is what's going to happen exactly :).

I did understand your points, however, I think/feel I didn't explain myself correctly.

For me it's just a matter of tradeoffs. And this project is quite complex in this regard.
On the one hand you have Kubernetes that keeps evolving at a "fast" pace with releases every 6 months. On the other you have dependent projects, libraries, and frameworks that get stuck on a given version of this library.
For me the goal is to keep things as stable as possible and as cross-compatible as possible so that there's no need to maintain multiple branches (major versions) of the project (which would likely be impossible with the amount of resources we have).
Keeping the lowest possible java baseline while things stay simple enough is one of those tradeoffs.
I suppose folks maintaining other popular libraries and tools such as JUnit face similar conundrums.

[jorsol]

For me it's just a matter of tradeoffs. And this project is quite complex in this regard. On the one hand you have Kubernetes that keeps evolving at a "fast" pace with releases every 6 months. On the other you have dependent projects, libraries, and frameworks that get stuck on a given version of this library. For me the goal is to keep things as stable as possible and as cross-compatible as possible so that there's no need to maintain multiple branches (major versions) of the project (which would likely be impossible with the amount of resources we have). Keeping the lowest possible java baseline while things stay simple enough is one of those tradeoffs. I suppose folks maintaining other popular libraries and tools such as JUnit face similar conundrums.

I agree, there will be always tradeoffs, probably the most important thing is to be as stable and cross-compatible as possible, if one of the tradeoffs is to drop support for an older Java version to keep things stable and maintainable, then is a very welcome tradeoff.

[martinwunderlich-celonis]

Hello all, I am wondering what the expected release date for version 7.0.0 currently is? We'd like to upgrade soon to get the new kubernetes client and get rid of the bouncy-castle dependency. Thanks!

[manusa]

We've made a lot of progress and we should be able to release in a couple of weeks.
In the meantime, you should be able to try the snapshots and report any bugs that might have come up while implementing the new features and after the refactoring efforts for the current ones.
If you're on the latest 6.13 release, the upgrade effort should be minimal.
Please, also check the Migration Guide and report anything that might be missing.

[martinwunderlich-celonis]

@manusa Thanks a lot for the quick feedback. I have already tested with a local snapshot build and it all works fine. We haven't discovered any bugs and are looking forward very much to the release. :)