This would potentially break exiting installations that rely on this values being set by default

@hagaibarel correct.
well, c'est la vie.
But this is easy to fix for anyone.
Currently I'm kinda fixing my setup for myself too, by providing null and I could ignore the "issues" completely.
I just wanted to make this chart for the community better.
Otherwise for how long are you going to haul this """not-that-smart""" non-standard piece in values.yaml?

c'est la vie

This isn't my preferred way of maintaing an OSS project where we have a community and users to support. If we wanted to introduce a change that would break people's exiting installation, this should have been a major version release, not a patch (or even a minor).

Otherwise for how long are you going to haul this """not-that-smart""" non-standard piece in values.yaml?

Given that there isn't a "standard" in values file, it's common to provide sane defaults with an option to override / change them.

Bottom line, I don't think this change has any meaningful value

added comment to the issue. I can bump chart version to 2.0.0

I don't think this change justifies bumping a major version, nor has any significant value.

There is an option to override the annotations if needed, and the defaults make sense and fit most use cases.

The override option is not functioning 100% as one would think by default and is not covering all cases.

Can you provide a real world use case from your experience where overriding didn't address the issue?

Can you provide a real world use case from your experience where overriding didn't address the issue?

I have provided exact example in the original issue linked to this PR.
Real world fact is that maps in Helm are not overridden but merged.