Consider removing "Get" prefix from cluster.Cluster interface

[vincepri]

The current Cluster interface https://github.com/kubernetes-sigs/controller-runtime/blob/f127c11669de63e97a0e568b53b09362c8735154/pkg/cluster/cluster.go#L39-L75

exposes a number of methods that start with Get[...], could we consider a breaking change to remove these?

[FillZpp]

After that, how should user get those client/cache from it?

[Noksa]

After that, how should user get those client/cache from it?

Using new methods without ‘Get’ prefix

[sbueringer]

Sounds fine to me assuming it is consistent with the rest of the code base. Would be good to have consistent naming for our getters

[troy0820]

/kind feature

This would be a minor breaking change so v0.17.0, v0.18.0 👀 ?

[sbueringer]

If we have consensus that we want to do it (@alvaroaleman @vincepri ?), whenever is fine I guess :)

[vincepri]

Definitely a breaking change, needs a minor version and requires detailed notes

[alvaroaleman]

I do agree the name is cleaner without the Get but this will be a lot of churn for users. Is that really worth it?

[troy0820]

I do agree the name is cleaner without the Get but this will be a lot of churn for users. Is that really worth it?

I'm not sure if it is worth it. The pushback around breaking changes from < v0.15 has caused issue triage and education around migration that is putting the onus on the maintainers and contributors alike. I don't disagree that the cleaner function names offer better usability, but if we know we are putting a lot into v0.17 already (I'm not saying we are) would this churn bloat the release to cause that same type of issue going forward?

[vincepri]

We can keep it for later, there is no reason to do this immediately.

On Nov 20, 2023 at 12:47:48 PM, Troy Connor @.***> wrote:

I do agree the name is cleaner without the Get but this will be a lot of churn for users. Is that really worth it?

I'm not sure if it is worth it. The pushback around breaking changes from < v0.15 has caused issue triage and education around migration that is putting the onus on the maintainers and contributors alike. I don't disagree that the cleaner function names offer better usability, but if we know we are putting a lot into v0.17 already (I'm not saying we are) would this churn bloat the release to cause that same type of issue going forward?

— Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/controller-runtime/issues/2181#issuecomment-1819780313, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXZJ77FA257G5RQCNPOP23YFO6XJAVCNFSM6AAAAAAUTDMMAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJZG44DAMZRGM . You are receiving this because you were mentioned.Message ID: @.***>

[sbueringer]

IIRC we didn't have a lot of breaking changes since the last release (at least I didn't see a many / any (?) PRs flagged accordingly).

I think it's mainly a question of do we think it's worth the breaking change / migration effort for users. If we don't think it is, I would just close this issue.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.