Unify each pkg version in kustomize repo

[koba1t]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

I am considering using the same version number for each module of kustomize. This means that all kyam, api, and kustomize modules that currently have different versions will be released with the same version.
The current release flow requires determining whether each module is a major or minor release. This makes it difficult to create an automatic release process, as the version change must be determined from the commit differences.

For example

current

kyaml v0.17.2
cmd/config v0.14.2
api v0.17.3
kustomize v5.4.3

plan

kyaml v5.5.0
cmd/config v5.5.0
api v5.5.0
kustomize v5.5.0

Why is this needed?

If we use a single version for every module, we can decide that the release is one of the major/minor/patch releases, and we can kick a release workflow with one release tag to make someone.

Can you accomplish the motivating task without this feature, and if so, how?

We have been working on release automation with the below PR. But This policy had issues with how to determine the release version of each pkg in order to proceed.
For example, we sometimes use the tide/merge-method-squash label to squash commits on PR or one of the contributors may not be able to use git well enough to change the commit message.
#5520

What other solutions have you considered?

It was suggested in the PR to have the commit message describe the scope of impact of the commit, and to select which of the major/minor/patch releases is the next version from the scope of impact in the release workflow of each pkg.

Anything else we should know?

Maybe We are facing a few problems

• Current Users of each pkg may be surprised by the Huge bump in the version
• When an urgent release is made, for security reasons, it may be possible to create a package that increases the version without any changes, depending on the situation.

Feature ownership

• I am interested in contributing this feature myself! 🎉

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

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.