See https://github.com/Kong/charts/pull/886 re Chart.lock stuff. We don't have a clear version management policy re kong versions used by ingress, but it seems like we can express anything we need via Chart.yaml ranges.
Helm dependency handling for umbrella charts is... not what I expected. Code safari is needed to confirm, but black box testing on a fork suggests that:
Minimum-only ranges with patch values like >= 1.2.0 will use that exact patch version regardless of what's available past it. New minor or patch versions aren't used automatically for upgrades or new installs after a helm repo update that makes the new dependency available.
Relative ranges like ~2.3 (which should be shorthand for a combination minimum and upper bound) will use patch versions beyond .0, but...
Dependency versions are apparently pinned in the upstream repo at release time. If you set 0.4.0 to require (dependency) ~2.3 and 2.3.1 is available when 0.4.0 releases, installs will use 2.3.1. However, if you release 2.3.2 of a dependency after, installs/upgrades to 0.4.0 will still use 2.3.1.
A subsequent 0.4.1 (that doesn't actually change anything other than the umbrella chart version) after 2.3.2 becomes available will use 2.3.2.
The index updates only use the Chart.yaml version ranges, but the release artifacts include a Chart.lock and a complete copy of the dependency chart, which will presumably pin it one way or the other. This is rather inconvenient.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]
[x] PR is based off the current tip of the main branch.
[x] Changes are documented under the "Unreleased" header in CHANGELOG.md
[x] New or modified sections of values.yaml are documented in the README.md
What this PR does / why we need it:
Releases the ingress 0.7 release, which bumps the kong dependency version to 2.28.
Removes the Chart.lock.
Special notes for your reviewer:
tl;dr do not merge this until after https://github.com/Kong/charts/pull/886 merges and releases.
See https://github.com/Kong/charts/pull/886 re Chart.lock stuff. We don't have a clear version management policy re
kongversions used byingress, but it seems like we can express anything we need via Chart.yaml ranges.Helm dependency handling for umbrella charts is... not what I expected. Code safari is needed to confirm, but black box testing on a fork suggests that:
>= 1.2.0will use that exact patch version regardless of what's available past it. New minor or patch versions aren't used automatically for upgrades or new installs after ahelm repo updatethat makes the new dependency available.~2.3(which should be shorthand for a combination minimum and upper bound) will use patch versions beyond.0, but...0.4.0to require (dependency)~2.3and2.3.1is available when0.4.0releases, installs will use2.3.1. However, if you release2.3.2of a dependency after, installs/upgrades to0.4.0will still use2.3.1.0.4.1(that doesn't actually change anything other than the umbrella chart version) after2.3.2becomes available will use2.3.2.The index updates only use the Chart.yaml version ranges, but the release artifacts include a Chart.lock and a complete copy of the dependency chart, which will presumably pin it one way or the other. This is rather inconvenient.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]
mainbranch.