search

fabric8io / kubernetes-client

Java client for Kubernetes & OpenShift
http://fabric8.io
Apache License 2.0
3.41k stars 1.46k forks source link

[INITIATIVE] Fabric8 Kubernetes Client 7.0.0 #5778

Open manusa opened 8 months ago

manusa commented 8 months ago

Description

Placeholder issue for activities related to the v7 major release.

Tasks

jorsol commented 4 months ago

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 commented 4 months ago

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 :facepalm:.

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.