operator-framework
releases: investigate different method of generating changelog
Feature Request
Describe the problem you need a feature to resolve.
Currently, the changelog is generated from changelog/fragments in CHANGELOG.md, and soon to be in changelog/generated/<version>.md. The changelog and deleted fragments need to be committed in a release commit. Ideally this release commit would either be smaller or non-existent, which implies that the changelog be committed in some other way or not at all.
Describe the solution you'd like.
My main suggested solution is to use goreleaser's default changelog generator. This means that we'll have to start enforcing a commit message structure, which I think is a reasonable thing to do, and helpful regardless of whether we generate a changelog from them or not.
/kind feature
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale