I would like to propose a process to "lock" a helm release to a specific version so it is safe from `helm upgrade` and other situations that may cause unintended breaking changes.
There are a variety of ways to prevent breaking users with helm charts. Here are a couple I've investigated but both have limits.
Publish charts to different repos. This adds a lot of burden on the publisher to make sure all compatible versions are in a specific repo and users have to switch repos to upgrade.
Use deprecation messages to require user action before upgrading.
These methods should still be used if the maintainer wants to make sure user upgrades are safe, but it would also be good for consumers of the chart to not accidentally upgrade charts. There may be cases where a repo has stable and unstable versions. In that case it would be best if the user can "lock" their version to a stable release.
I envision a helm lock could work similar to yum versionlock or apt mark. A user can install a specific version of the chart and then run `helm lock nginx-ingress-vX.X.X` and any additional helm upgrades will ignore versions beyond that version. It may also be desired to allow a user to `helm install $CHART --lock` which will automatically lock to the currently available version or they can specify `--version $VERSION` to request a version.
Ideally this lock would be stored in the release's secret metadata and helm will use it if it is available. Without the metadata `helm upgrade` works the same way as it always has.
Users can also `unlock` their releases and locks could appear in helm list or other places metadata about a release is surfaced.
Please let me know what you think so I can write up a HIP if this feature would benefit the community. If there is prior discussion about this I would also be interested in reading it.
