@jainankitk The changelog on the 3.3 branch should be empty as all changes will be released in 3.3. After the release, the only entries in the 3.3 changelog would be any changes to go in a 3.3.1 patch (if such a patch release were needed).

@jainankitk The changelog on the 3.3 branch should be empty as all changes will be released in 3.3. After the release, the only entries in the 3.3 changelog would be any changes to go in a 3.3.1 patch (if such a patch release were needed).

I was just trying to keep things consistent, since other entries were not removed. Ideally we should update the release notes generation workflow to update CHANGELOG as well at the same time?

Hi @jainankitk @andrross

Since we start using the autogen AI workflows from infra side to generate release notes for every component,
I wonder if we still need the changelog.md?

1. It cause conflicts previously and every update to it will go through gradle check
2. Our workflow will autogen based on commit msgs, if the changelog.md exist it will skip and just skip commit msgs and take directly from changelog.md.

Thanks.

@peterzhuamazon I think that would be our single biggest improvement for engineering efficiency. Only comment I would have are:

• Would the skip-changelog label be honored? For instance I don't think this PR needs an entry
• We need to educate maintainers to make sure the commit message is formed well on squash and merge (or potentially Github will have smart summarization soon?)

@cwperks the autogen logic is simple.
If changelog.md does not exist, take everything in commit history from last release to HEAD and create release notes.
Else if will just copy from changelog.md.

I guess one way is to improve our workflows here is to add an --exclude option for certain keyword in commit msg.

Then if any PR title (since we squash and PR title becomes final commit msg) contains these:

[NFC] - "No Functional Change"
[nit] - Short for "nitpick," indicating a tiny change
[chore] - Minor maintenance work
[trivial] - Self-explanatory minor change

We will just ignore them in the release notes.

Thanks.

As for educating the maintainers, I guess at least the PR title needs to be precise and detailed enough, so that LLM can improve them upon. I think since we are using LLM this step is not as hard as we think, just informing people to add [NIT] or [Chore] should be the only requirement if we implement above.

@cwperks @peterzhuamazon Let's move the discussion to #19600