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.

[soltysh]

I'd strongly object to switching the versioning scheme from v0.x.y to v5.x.y, since that will force everyone to change their import paths. For example, after you switch

kyaml v0.17.2

to

kyaml v5.5.0

the import path for that library will change from:

import "sigs.k8s.io/kustomize/kyaml"

to

import "sigs.k8s.io/kustomize/kyaml/v5"

All the subsequent changes to major version (here v5) will trigger similar change for all the consumers of this library.

See excerpt from https://go.dev/ref/mod#modules-overview:

By definition, packages in a new major version of a module are not backwards compatible with the corresponding
packages in the previous major version. Consequently, starting with v2, packages need new import paths. This is
accomplished by adding a major version suffix to the module path. Since the module path is a prefix of the import path
for each package within the module, adding the major version suffix to the module path provides a distinct import path > for each incompatible version.

That is one of the reasons why kubernetes releases versions are v1.x.y, but all the libraries (client-go, api, etc.) are versioned v0.x.y. Compare kubernetes tags with client-go tags.

I'm supportive aligning the versions, but sadly the versions for kyaml, cmd/config and api moved faster than kustomize, which means you'd either have to catch up the numbers with kustomize like this:

kyaml v0.17.2
cmd/config v0.17.2
api v0.17.2
kustomize v5.17.2

or keep libraries (kyaml, cmd/config and api) at a single version, but different from kustomize, like this:

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

Either of the two should work, imo.

[koba1t]

Hi @soltysh
Thanks for your advice!
We changed to the version policy that refer to your advice!

We complete to make new kustomize releases that use unified internal pkg versions!
https://github.com/kubernetes-sigs/kustomize/releases/tag/kustomize%2Fv5.6.0
https://github.com/kubernetes-sigs/kustomize/releases/tag/kyaml%2Fv0.19.0
https://github.com/kubernetes-sigs/kustomize/releases/tag/cmd%2Fconfig%2Fv0.19.0
https://github.com/kubernetes-sigs/kustomize/releases/tag/api%2Fv0.19.0

And, those releases are already introduced in k/k repo.
kubernetes/kubernetes#129622

[koba1t]

/close

[k8s-ci-robot]

@koba1t: Closing this issue.

In response to this:

/close

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.