search

kubernetes-sigs / kustomize

Customization of kubernetes YAML configurations
Apache License 2.0
10.89k stars 2.24k forks source link

Tags and Releases named by the version number only. #4601

Closed Harmelodic closed 2 years ago

Harmelodic commented 2 years ago

Is your feature request related to a problem? Please describe.

Some automation tools, like Renovate, are able to update versions based on Releases/Tags of software on GitHub.

With weird names for tags/releases, it makes it much harder to do automated updates.

Describe the solution you'd like

Tags and releases named like: 4.5.2

k8s-ci-robot commented 2 years ago

@Harmelodic: 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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
k8s-triage-robot commented 2 years ago

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

This bot triages issues and PRs according to the following rules:

You can:

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

/lifecycle stale

k8s-triage-robot commented 2 years ago

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

This bot triages issues and PRs according to the following rules:

You can:

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

/lifecycle rotten

Harmelodic commented 2 years ago

/remove-lifecycle rotten

natasha41575 commented 2 years ago

Tags and releases named like: 4.5.2

We aren't having "weird release tags" for no reason. We maintain multiple modules in this repo that are released separately (kyaml, api, cmd/config, and kustomize). A release tag like 4.5.2 won't work for us, because (a) we will have conflicting release tags for our modules and (b) it doesn't tell us which module the release is for. The ambiguity is bad for both us and the automation tool.

If there is a precedent elsewhere in the kubernetes ecosystem or generally on Github for individual and multi-module releases, then we can consider following that convention. There is at least one other example that I can find with multi module release tags (link), which has tags like module-v0.0.0. This is different from our module/v0.0.0, but AFAICT, there isn't a standard.

I would argue that it is the responsibility of the automation tool, not kustomize, to understand and decode release tags in multimodule repos. There are ways besides the release tags to find latest releases (such as a curl of the releases page) which may be worth looking into. Happy to reconsider the format of our tags if there does appear to be a multimodule repo convention that we aren't following.