Remove deprecated methods

[jorsol]

Kubernetes Client 5.0 already breaks many things, so why not do a cleanup for all the deprecated methods?

We are talking about a MAJOR version upgrade, so it should be "safe" to break API compatibility here and have a clean API.

Some examples include:

KubernetesClient.customResourceDefinitions();
KubernetesClient.customResources(CustomResourceDefinition crd, Class<T> resourceType, Class<L> listClass);
KubernetesClient.customResource(CustomResourceDefinition crd, Class<T> resourceType, Class<L> listClass);
KubernetesClient.events();
...
(and all others)

This has the potential risk that people migrating to this version would not know what it's the alternative, but the risk could be reduced by writing the items in the migration guide.

Probably this would be undesirable, but there are few major upgrades that allow being this harsh. But if the intention is to be more polite, then please close this now.

[manusa]

Hi Jorge,

Thanks for your input, it is much appreciated. I do agree that it's the time to remove these deprecated methods.

However, we're on a very tight schedule (must cut final release in the coming week), and most of the team is on PTO or starts PTO today.

All of these methods are annotated with @deprecated javadoc entry or @Deprecated annotation (and some have been for a while).
I'm not sure if in these situations it's OK to remove such methods in minor version releases (I've seen this). We are also not following a strict SemVer policy since our models are based on K8s APIs including alpha and beta version that keep changing every release.

The safest approach (IMHO), given our current situation, is to add a deprecation target version in the docs (e.g. @deprecated To be removed in 5.1.0 use ... and a clear notice in the changelog and address these changes in the future.

WDYT?

[jorsol]

Well, since there is no strict SemVer policy, adding a target version in the docs should be fine 👍