If the bot is not involved fixing the changelog folder, ideally we shouldn't require a folder. maybe take an approach like in istio, where all release notes go in one folder?
or Envoy, where post-release the changelogs are organized into folders?

I really dont like the envoy strategy.
The fact that the last commit to a changelog is always the "rename" one makes git blame alot more painful.

That being said would be interested to chat more on the desired format.

we discussed in slack but to summarize here - i don't care about the format; but rather the devex of moving the changloge file to the right folder mid-PR

@nfuden git blame has an --ignore-rev flag that can ignore certain commits when blaming a file. I'm not sure how well it works if the file was renamed though. It's mostly used for ignoring commits that reformat files or whitespace changes, etc.

Yeah but I like the basic vscode integration for lens

+1 to @yuval-k's comment. Having to move the changelog entry around mid-pr is not great. If we get a chance to begin again I'd definitely like to go with something that avoids having to deal with those moves.

I threw up a WIP enhancement for adopt k/k's style of changelog mangement: #10381. There are other alternatives to explore, but this felt like a reasonable balance.

For the initial 2.0.0 release, we will rely on handcrafted release notes and look to implement the automated approach post-release

Have this working in my fork:

• Add https://github.com/kgateway-dev/changelog-generator/ as a tool dependency
• Calculate the start and end SHA needed for the changelog generator to run properly
  • Search for any merged PRs that have the release-note label, for each PR extract the release note and bucket into a map, aggregate all the bucketed release notes into formatted markdown output
• Update the .goreleaser.yaml configuration to conditionally enable the "changelog" stanza via an env var
• Update the release workflow to add a "changelog" job which is responsible for setting the goreleaser env var, calculating the starting and end SHA values, and writing the generator changelog to a file that will be consumed by goreleaser

We don't immediately need this unless we want to cut a beta anytime soon. I'll at least upstream my fork's branch and we can decide there.

The #11242 hooks up the changelog generator to the release workflow. I tested this works in my fork by cutting a v2.1.0-beta1 tag and validating that any merged PR with the "release-note" label between the v2.0.0 tag and the current HEAD of main was present in the GH release.

Remaining work:

• Fix Respect the start and end sha inputs changelog-generator#7 which is highly relevant to patch releases due to a limitation with the GH search API (cannot query per-branch)
• Evaluate whether the pr-kind-labeler should be a custom GHA vs. a tool dependency (the latter would be consistent with the approach taken for integrating the changelog generator into the repo)
  • If custom action: pin the action to a specific commit. Right now, it pulls from the latest commit on the pr-kind-labeler main branch
• Backfill any merged PRs that need release notes before the new workflow was onboarded to the repository
• Backport this mechanism to the v2.0.x release so net new patch releases can have custom release notes
• Update the org-wide .github/PULL_REQUEST_TEMPLATE.md to match the current state of the pr-kind-labeler implementation. Remove any embedded templates from repositories that follow this changelog format (including this one)