skip to content

What does Helm's --devel flag change when you install or pull a chart?

level: middleimportance: nice to knowfreq 29%

answer

  1. Some published versions are invisible by default
  2. A segment after a hyphen changes matching
  3. Documented as one permissive version range
  4. The range floor ends in a prerelease zero
  5. An explicit version request overrides it

basics

~20 s

It lets prerelease chart versions such as 2.97.0-rc.1 be selected. Helm normally skips any version with a prerelease segment when resolving, and --devel is documented as equivalent to asking for the range >0.0.0-0. An explicit --version wins over it.

solid answer

~40 s

Semantic-version matching excludes prereleases by default, so when Helm resolves a chart name with no explicit version it takes the highest **stable** version and ignores `2.97.0-rc.1` entirely. `--devel` opts in: it is documented as equivalent to a version constraint of `>0.0.0-0`, and the trailing `-0` prerelease floor is exactly what makes prerelease versions match. It is available on the commands that resolve a chart — `helm install`, `helm upgrade`, `helm pull`, `helm show`, `helm template`, `helm search repo` — and it is ignored when `--version` is given explicitly, since you have already said which version you want. For a chart publisher it means a release candidate can sit in the same repository as the stable line without anyone installing it by accident.

code

bash · 9 lines
bash
# repository holds invoice-worker 2.96.0 and 2.97.0-rc.1
helm search repo internal/invoice-worker
helm search repo internal/invoice-worker --devel

# stable resolution ignores the candidate
helm install invoices internal/invoice-worker

# opt in to the candidate
helm upgrade invoices internal/invoice-worker --devel

go deeper

for a junior

Recognise that a chart version with a hyphenated suffix such as 2.97.0-rc.1 is a prerelease, that ordinary installs skip it, and that --devel is the flag that opts in.

for a middle

Explain why prereleases are excluded by semantic-version matching, what the documented equivalent range >0.0.0-0 means, and which commands accept the flag.

for a senior

Use it as a canary channel: publish a candidate, direct one consuming team to it, promote by publishing a new stable version rather than renaming the candidate.

for a principal

Decide whether your organisation runs a prerelease channel at all, who is allowed to consume one, and how you stop candidates becoming long-lived production versions nobody promoted.

## The rule underneath the flag Semantic Versioning treats `2.97.0-rc.1` as *less than* `2.97.0`, and — more importantly here — range matching deliberately excludes versions carrying a prerelease segment unless the request itself mentions one. Helm inherits that behaviour wherever it resolves a chart reference. So with a repository holding `invoice-worker` at 2.96.0 and 2.97.0-rc.1: ```bash # resolves to 2.96.0 — the release candidate is invisible helm install invoices internal/invoice-worker # resolves to 2.97.0-rc.1 — prereleases are now candidates helm install invoices internal/invoice-worker --devel # --devel is ignored: an explicit version was requested helm install invoices internal/invoice-worker --devel --version 2.97.0-rc.1 ``` The flag's own help text describes it as "use development versions (alpha, beta, and release candidate releases), too", and as equivalent to a version constraint of `>0.0.0-0`. That constraint is worth decoding: `>0.0.0` on its own would still exclude prereleases, but the `-0` suffix gives the constraint a prerelease segment of its own, and a constraint that mentions a prerelease is allowed to match prereleases. `--devel` is not a special resolution mode; it is a maximally permissive range. ## Where the flag lives `--devel` appears on the commands that turn a chart *reference* into a concrete version: `helm install`, `helm upgrade`, `helm pull`, `helm show`, `helm template`, and `helm search repo`. That last one is the one people forget — a release candidate you published will not appear in `helm search repo` output either, which regularly convinces someone the push failed when it did not. It has no effect at all when you name a version outright, whether that version is stable or a prerelease. Naming `--version 2.97.0-rc.1` is itself a constraint that mentions a prerelease, so it matches without help. ## Why a chart author cares This is the mechanism that gives a chart a canary channel without a second repository. Publish `2.97.0-rc.1` alongside 2.96.0 and: - every consumer who installs or upgrades normally stays on 2.96.0, including anyone tracking a range; - a team that agreed to test the change opts in with `--devel` or by naming the exact version; - when the candidate is accepted you publish `2.97.0` — a *new* version, never a rename of the candidate — and everyone else picks it up on their next upgrade. The discipline that goes with it: a prerelease is still an immutable published version. `-rc.2` follows `-rc.1`; you never re-push `-rc.1` with different content, for the same reason you never re-push a stable version. ## The naming trap Prerelease identifiers are compared dot-segment by dot-segment, and a segment made only of digits is compared numerically while anything else is compared as text. So `2.97.0-rc.10` correctly sorts above `2.97.0-rc.9`, but `2.97.0-rc10` sorts *below* `2.97.0-rc9`, because `rc10` and `rc9` are compared as strings. Separate the counter with a dot and the tenth candidate does not quietly rank below the ninth. ## What it does not do `--devel` is about version *selection* only. It does not relax validation, does not change how the chart renders, does not mark the resulting release as special, and leaves no trace on the installed release beyond the chart version it selected. A release installed from a candidate looks like any other release; `helm list` simply shows `invoice-worker-2.97.0-rc.1` in its CHART column, which is how you find the clusters still sitting on a candidate after the stable version shipped.

  • You publish 2.97.0-rc.1 and a colleague says helm search repo does not show it. What do you tell them?
    That the push worked and search is filtering it. `helm search repo` excludes prerelease versions the same way installation does; adding `--devel` reveals it. Asking for the exact version with `--version 2.97.0-rc.1` also works, since a constraint that names a prerelease is allowed to match one.
  • Does --devel do anything when you also pass --version?
    No — it is ignored. `--version` is already a constraint, and if that constraint names a prerelease it matches prereleases on its own. The flag exists for the case where you have named only the chart and left the choice of version to Helm.
  • Why publish a release candidate into the same repository as the stable line rather than a separate prerelease repository?
    Because prerelease exclusion already isolates it: normal installs and upgrades cannot pick it up, so a second repository buys nothing and costs configuration on every consumer. One repository also keeps the version history in one ordered line, so the candidate that became 2.97.0 sits next to it rather than in a parallel namespace.

saying these in an interview costs you the question

  • Thinking --devel enables experimental Helm features
  • Saying it installs from a local directory
  • Believing prereleases are picked up by ordinary upgrades
  • Expecting --devel to override an explicit --version
  • Re-pushing an rc tag with new content
  • Numbering candidates rc9, rc10 without a separator dot

context

resolving links…