Expanding the release changelog a bit

[robertd]

Hello,

Would it be possible to add docs and chore sections to the release changelog? That way we wouldn't have to dig through all the commits to see what else was changed/updated/removed and was tagged with docs or chore. Sometimes things get deprecated and they slip under the radar.

Thanks in advance.

[rix0rrr]

Hi Robert,

Do you have examples of cases where you were interested in something, would have expected to find it in the change log, but didn't?

My instinctual reaction is that these other commits are not user visible, and therefore shouldn't be included into the CHANGELOG (I know, docs is debatably user impacting and we could consider including them, chore less so imo).

That way we wouldn't have to dig through all the commits to see what else was changed/updated/removed

Well... by that point every single commit will lead to a line in the CHANGELOG. So wouldn't digging through the change log be equivalent to digging through the commit history at that point? 🤓

I have a feeling there's a more specific question behind the question. It might help to look at examples?

[robertd]

I have a feeling there's a more specific question behind the question. It might help to look at examples?

Sometimes things get deprecated and they slip under the radar. We often see reverts that are chore related. As a contributor, changelog is the only place where we can see what's going on between the versions given that there are so many cooks in the kitchen. 😄

My instinctual reaction is that these other commits are not user visible, and therefore shouldn't be included into the CHANGELOG (I know, docs is debatably user impacting and we could consider including them, chore less so imo).

Perhaps having a full blown changelog between versions vs highlights-only changelog for release (with bug fixes and features only) would be an option.

Well... by that point every single commit will lead to a line in the CHANGELOG. So wouldn't digging through the change log be equivalent to digging through the commit history at that point?

Haha... touché 🤣

All in all, I'm just thinking out loud what would be the best course of action to get all the changes in one place that builds on top of Conventional Commits (https://www.conventionalcommits.org/en/v1.0.0/).

Anyway, treat this as random ramblings from a fellow contributor... nothing else 😄

[rix0rrr]

In response to these examples:

Sometimes things get deprecated and they slip under the radar.
We often see reverts that are chore related.

Reverts may be chores, but only if the change they are reverting hasn't been released yet. In that case, the revert isn't user-impacting. If the change has been released, then it should become a fix like any other.

Neither of these should be the case, so if that happens we need to explain the PR naming rules a bit better inside the team. I'll take that up.

[robertd]

Makes sense. Frankly, the more I think about this the more I lean toward using `git log —oneline` and grep-ing around and finding what I need between the releases. Thanks for chiming in and bringing me to my (common) senses Rico :)

…

On Mon, Mar 13, 2023 at 1:25 AM Rico Hermans ***@***.***> wrote: In response to these examples: Sometimes things get deprecated and they slip under the radar. We often see reverts that are chore related. Reverts *may* be chores, but only if the change they are reverting hasn't been released yet. In that case, the revert isn't user-impacting. If the change has been released, then it should become a fix like any other. Neither of these *should* be the case, so if that happens we need to explain the PR naming rules a bit better inside the team. I'll take that up. — Reply to this email directly, view it on GitHub <#24559 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHWN3TIHVD35YTZJFYH4LW33KX5ANCNFSM6AAAAAAVV7EHRY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.