Custom fields in Charts.yaml "not allowed" in helm version >= 3.2.2

[consideRatio]

Helm documentation about the Chart.yaml file describes:

As of v3.3.2, additional fields are not allowed. The recommended approach is to add custom metadata in annotations.

This is relevant for frigate's use of custom fields in a Chart.yaml file, I've seen long_description and footnote for example. So far, it seems that including additional fields hasn't broken something though. For example, using helm v3.9.0, I can still call helm template on a Chart.yaml with long_description inside it, so maybe their documentation was too strict?

Overall though, this is a big risk, and I think its a much better practice for frigate to not use these keys but instead used an annotation key/value. That way, the key would clarify that this configuration was frigate associated, something that has confused me up until today when I've seen this config in a Chart.yaml.

frigate/frigate/tests/mockcharts/rich/Chart.yaml

Lines 6 to 32 in 762e75b

	long_description: |
	This is the default chart created with ``helm create nginx``.
	Descriptions have then been added to all items in ``values.yaml`` and a ``.frigate.jinja2`` template has been included to enrich it.
	Frigate has then been used to generate both the ``README.rst`` in that directory as well as the example in the Sphinx docs.
	Generating the README.rst
	-------------------------
	.. code-block:: console
	$ frigate gen ../frigate/tests/mockcharts/rich > ../frigate/tests/mockcharts/rich/README.rst
	Sphinx docs directive
	---------------------
	.. code-block:: rst
	.. frigate:: ../frigate/tests/mockcharts/rich
	footnotes: |
	Footnotes
	---------
	It is also possible to include a footnotes section which is placed after the parameters table in your documentation.
	This is a good location for information which you want to include but may not be of primary interest to users.

[jacobtomlinson]

Totaly agree. This should just be a case of nesting the options under annotations: right?

[consideRatio]

Yepp! Note also that when defining an annotation key for the long description and one for the footnote, k8s has some naming conventions. I think the annotation key could be something like frigate.rapids.ai/long-description or rapids.ai/frigate-long-description for example, or the same with _ instead of - perhaps.

https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set