Releases contain identical binary with 2 different names

[nrb]

/kind bug

What steps did you take and what happened:

Starting with v2.4.2, we built binaries with the .goreleaser.yaml settings. This includes both clusterctl-aws and clusterawsadm, which are the same binary, just different names.

The clusterctl plugin docs state:

A plugin determines the command path it implements based on its filename. Each sub-command in the path is separated by a dash (-). For example, a plugin for the command clusterctl foo bar baz would have the filename clusterctl-foo-bar-baz.

Under our current naming scheme, the user will have to rename the binary to use it since we include the OS and platform in the filename.

However, all of our documentation and the Cluster API book rely on the clusterawsadm name, and this has broken in the past.

What did you expect to happen:

The client-side executable is built and included in a release only once. We need to come to consensus on what the name should be.

Anything else you would like to add:

Also of note, we provide instructions to brew install clusterawsadm.

There was a Slack discussion about this topic that I've tried to summarize in this issue.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPA/CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[nrb]

/area ux
/area clusterawsadm

[kranurag7]

continuing the slack discussion here, I think in the long term only publishing one binary is the way to go. For now, we can create a issue with clear title about the migration (that we are switching the binary names from clusterawsadm => clusterctl-aws) and pin it for few weeks and then update clusterawsadm reference upstream.

[nrb]

For brew, whomever takes on this task will need to follow https://docs.brew.sh/Rename-A-Formula, so moving https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/c/clusterawsadm.rb to a clusterctl-aws.rb file (note: I do not know if this is actually proper per the Brew naming guidelines) and adding an entry in formula_renames.json

[nrb]

During the Aug 05 2024 community meeting, we decided to use the clusterctl-aws name going forward.

I'll also take an action item to treat this as an API deprecation and look up the Kube policy for length on this (I think 3 minor releases or 9 months, whichever is longer, but not sure).

Also, the CLI should detect the clusterawsadm binary name and issue a warning around the deprecation.

[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

[nrb]

/remove-lifecycle stale

[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-sigs/prow repository.