Provide a changelog for Helm chart releases #8059
Description
Is your feature request related to a problem? Please describe.
Yes, this request addresses a problem with the current release process. There is no dedicated changelog for releases of the nginx-ingress Helm chart, which makes it difficult to track changes and manage upgrades safely.
The project's GitHub releases are tied to the controller's version (e.g., v5.1.0), not the Helm chart's version. For example, the v5.1.0 release tag corresponds to chart version 2.2.0. However, a newer chart version like 2.2.1 can be published to the Helm repository using the same appVersion: 5.1.0.
Because there is no separate release tag or official changelog for the 2.2.1 chart update, it is impossible to determine what modifications were made without manually downloading and comparing the contents of the two chart versions. This makes it difficult to assess the impact of an upgrade and identify potential breaking changes.
This also causes problems for automated tools like Renovate, which generate incorrect changelogs for pull requests by trying to link to the v2.2.1 tag of the ingress controller. This leads to confusion and undermines the automated change-tracking process.
Describe the solution you'd like
I would like a documented changelog to be published for each version update of the nginx-ingress Helm chart.
This could be implemented in one of the following ways:
- Creating GitHub releases that correspond to each Helm chart version, detailing the changes.
- Maintaining a
CHANGELOG.mdfile within thecharts/nginx-ingressdirectory. - Including a dedicated "Chart Changes" section within the release notes of the main application tag if a chart version was updated.
The goal is to provide a clear, accessible record of all modifications made in each chart release.
Describe alternatives you've considered
The only current workaround is to manually pull different chart versions and perform a diff to reverse-engineer the changes. This is time-consuming and doesn't explain the reasoning behind a change.
A more comprehensive, long-term solution would be to create a separate Helm chart repository for all NGINX Helm charts. This would allow the charts to have their own independent release cycle, versioning, and changelogs, fully decoupling them from the controller application's release schedule.