Managing Chart Versions

1. Using Semantic Versioning

IncrementTrigger
MAJORBreaking changes (renamed values, removed templates, schema-incompatible)
MINORBackward-compatible feature additions
PATCHBug fixes, doc updates
Pre-release1.5.0-rc.1, 1.5.0-alpha.2
Build metadata1.5.0+commit.abc123 (ignored in version comparison)

2. Incrementing Chart Version

ChangeBump
New optional valueMINOR
Renamed valueMAJOR
Image tag updatePATCH or MINOR (also bump appVersion)
Template restructureMAJOR if upgrade path requires migration

3. Setting Application Version

FieldPurpose
appVersionTracks application — independent of chart version
Always quotePrevents YAML coercion (e.g. 1.101.1)

4. Creating Version Constraints

ConstraintAllowed
1.2.3Exact
=1.2.3Exact (explicit)
!=1.2.3Not equal
>1.2.3 <2.0Composite range
1.x / 1.2.xWildcard

5. Using Version Ranges

Example: Composite

dependencies:
  - name: postgresql
    version: ">=15.0.0 <16.0.0"

6. Pinning Exact Versions

PracticeReason
Pin in productionReproducibility, avoid surprise breakage
Allow ranges in devPick up patches automatically
Commit Chart.lockLock resolved versions

7. Using Tilde Range

PatternMatches
~1.2.3>=1.2.3 <1.3.0 (patch updates)
~1.2>=1.2.0 <1.3.0
~1>=1.0.0 <2.0.0

8. Using Caret Range

PatternMatches
^1.2.3>=1.2.3 <2.0.0 (minor + patch)
^0.2.3>=0.2.3 <0.3.0 (0.x treated specially)
^0.0.3>=0.0.3 <0.0.4

9. Maintaining Changelog

Example: Annotations-based changelog

# Chart.yaml
annotations:
  artifacthub.io/changes: |
    - kind: added
      description: Support for ExternalSecrets
    - kind: fixed
      description: Probe timeout default raised to 30s
    - kind: deprecated
      description: 'imageTag' replaced by 'image.tag'

10. Tagging Chart Releases

Tag schemeExample
Chart name + versionapi-1.4.2 (chart-releaser default)
Version onlyv1.4.2 (single-chart repos)
ImmutableNever re-tag a published version