A chart's selectorLabels helper was changed to include the chart version - what breaks on upgrade?

## The two helpers and why there are two A chart from `helm create` contains a pair of label partials that look redundant until you see what each is wired to: ``` {{- define "platform-transcoder-euw-workers.labels" -}} helm.sh/chart: {{ include "platform-transcoder-euw-workers.chart" . }} {{ include "platform-transcoder-euw-workers.selectorLabels" . }} {{- if .Chart.AppVersion }} app.kubernetes.io/version: {{ .Chart.AppVersion | quote }} {{- end }} app.kubernetes.io/managed-by: {{ .Release.Service }} {{- end }} {{- define "platform-transcoder-euw-workers.selectorLabels" -}} app.kubernetes.io/name: {{ include "platform-transcoder-euw-workers.name" . }} app.kubernetes.io/instance: {{ .Release.Name }} {{- end }} ``` The outer helper is a superset of the inner one. `metadata.labels` on every object gets the full set; the workload's `spec.selector.matchLabels` and the Service's `spec.selector` get only the inner pair. Three of the four labels in the full set move: `helm.sh/chart` embeds the chart version, `app.kubernetes.io/version` tracks `appVersion`, and `managed-by` is stable in practice but conceptually descriptive. The inner pair is chosen precisely because nothing routine changes it — the chart name and the release name are fixed for the life of the release. ## What breaks A workload's label selector is immutable once the object exists. That is not a Helm rule and no Helm setting relaxes it. So the moment `selectorLabels` starts emitting `helm.sh/chart`, the chart has coupled an immutable field to a value that changes every time anyone publishes a new chart version. Picture an internal platform chart owned by the infrastructure team, driving a media-transcoding pipeline across 11 releases. Someone "tidies up" the helpers so that the selector matches the full label set. The change ships with chart version 4.2.9 and every release installs cleanly, because a fresh install writes whatever selector it is given. Nothing looks wrong for weeks. Then chart 4.3.0 is published, and the first `helm upgrade` renders a selector containing `helm.sh/chart: platform-transcoder-euw-workers-4.3.0` where the live object has `4.2.9`. The API server rejects the update on the immutable field. Helm marks the release `failed`, and — because Helm 4 waits for workloads only when asked — the error surfaces immediately as an apply error rather than as a timeout. ## Why the usual escapes do not help This is where candidates reach for flags. Server-side apply, the default write path for a Helm 4 install, does not make an immutable field mutable; field ownership decides *who* may write a field, not *whether* it may change. Replacement-style update flags are not a dependable escape either, because the rejection comes from the API server's validation of the object, not from how Helm chose to send it. The only reliable path is to remove the workload object and let Helm recreate it, which means a gap in service unless you plan a parallel cutover. `helm rollback` does work, and it is the right first move during the incident: the previous revision's manifests carry the old selector, so applying them is a legal update and the release returns to `deployed`. That buys time — it does not ship the new chart. ## The related trap: selector and pod labels drifting apart The mirror-image mistake is to make the selector *smaller* than the pod template's labels by accident — for example by pointing `spec.selector.matchLabels` at the full `labels` helper while the pod template uses something else. The selector must be satisfied by the pod template's labels; when it is not, the object is rejected outright at creation. The scaffold avoids both mistakes by including the selector pair inside the full set: pod labels are always a superset of the selector, by construction. ## How to keep it from happening Treat `selectorLabels` as a frozen interface. Anything derived from `.Chart.Version`, `.Chart.AppVersion`, an image tag, a commit SHA or a timestamp belongs in `labels` and never in `selectorLabels`; a comment in `_helpers.tpl` saying so costs one line and saves an outage. In review, any diff touching the `selectorLabels` define deserves the same scrutiny as a database migration. A render-time check in CI helps too: render the chart at two different chart versions and assert the selector block is byte-identical. That catches the change on the pull request rather than on the eleventh release.