-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify each pkg version in kustomize repo #5800
Comments
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 The 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. |
I'd strongly object to switching the versioning scheme from
to
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 See excerpt from https://go.dev/ref/mod#modules-overview:
That is one of the reasons why kubernetes releases versions are I'm supportive aligning the versions, but sadly the versions for
or keep libraries (
Either of the two should work, imo. |
Hi @soltysh We complete to make new kustomize releases that use unified internal pkg versions! And, those releases are already introduced in k/k repo. |
/close |
@koba1t: Closing this issue. In response to this:
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. |
Eschewed features
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
plan
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
Feature ownership
The text was updated successfully, but these errors were encountered: