clarify one-time v0.17.0 chart-restructuring migration vs. routine upgrades
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- Half a day
- Newbie friendliness
- 72/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- helm
- Domain
- documentation
Research direction
Start in the linked Upgrade Guide and compare the General Upgrade Process with the v0.16.0 to v0.17.0 migration section and its example commands. Separate the one-time v0.17.0+ chart-layout migration from routine split-chart upgrades, document the plain helm upgrade --reuse-values pattern, and include checking current chart names with helm list -n kserve.
Written by the indexing model from the issue text.
Description
The Upgrade Guide doesn't clearly distinguish between :
- A one-time migration needed to move onto the v0.17.0 chart layout (CRD-annotation/ownership etc.)
- Ordinary upgrades between versions that are already on that layout (e.g. v0.17.0 → v0.18.0 → v0.19.0)
The "General Upgrade Process" section currently reads:
For v0.17.0 and later, the Helm chart architecture has been completely restructured... you must follow the specific migration steps outlined in the v0.17.0 section below.
The ambiguity is compounded by the migration steps themselves living under a "v0.16.0 to v0.17.0" heading while their example commands target --version v0.18.0.
Suggested fix: split the guide into something like "One-time migration: moving onto the v0.17.0+ chart layout" (current steps, framed explicitly as a single historical transition) and "Routine upgrades between split-chart versions" (a short section showing the plain helm upgrade --reuse-values pattern per chart, with a tip to confirm current chart names via helm list -n kserve first).
- Dominant language
- MDX
- Stars
- 113
- Forks
- 193
- Avg merge
- 5d 20h
- Merged PRs (30d)
- 3
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from kserve/website
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-2 days Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Similar issues
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Ecosystem: ClawMetry — the Qwen Code reader is now free and open source (follow-up to #9294 / #9338) Opencategory/integration priority/P3 scope/documentation status/ready-for-human type/feature-request
Difficulty 1/5 Under an hour Newbie friendliness 84/100