r33 changelog (preview)

[gokcehan]

Unreleased Changes

(There are no changes yet)

[gokcehan]

@joelim-work The development was quite active recently and I'm not sure if we spent enough time for the feature freeze for r32. So I was thinking it could be nice to wait for a couple of days or a week before merging the current PRs in case there is a serious bug in r32 that we want to quickly fix with a followup release. That's why I haven't merged anything yet.

[DusanLesan]

@gokcehan @joelim-work Suggestion: Use milestones

Using milestones would enable us to quickly identify which release includes a particular fix or feature. For example, having release V32 out, adding a milestone for V33 to any new pull requests while merging would allow us to track fixes that are pending release or help in determining if a specific merged fix has been included in a release.

I recently encountered an issue fixed in this pull request and wished for a way to list all unreleased changes and had to use merge dates. Using dates is not optimal as I often forget the dates even for my own projects, let alone open-source ones and lists like this can be incomplete.

[joelim-work]

Normally I somewhat avoid making these kind of decisions, though I haven't heard from @gokcehan for a couple of months now (probably taking a long deserved break) so I will chime in here.

I haven't used milestones before, but after taking a quick look at it, it appears to solve what this issue is trying to do (track unreleased changes) without the need for creating a placeholder issue in the first place. Milestones can also contain descriptions, so it can be updated to show the above list of changes which will eventually go into the release notes.

The other thing is that milestones makes it easier to see which release a particular PR/commit is tied to, without having to do a git log and search for neighboring release tags. This means that it's possible to say things like:

• "this bug was fixed in #1234, so should be available from version r31 onwards"
• "this bug was fixed in #2345, and is not released yet but will be available in release r32"

Overall I am open and somewhat keen to try this out.

[DusanLesan]

Using labels as well could be helpful to somewhat automate making release notes. Add like fix and breaking labels and later on you can use github cli to filter out by milestone and output fields you want.

Like:
gh pr list -S 'milestone:"V33"' -s 'merged' -L 1000 --json 'title,author,url,labels' | jq -r '.[] | "(\(.labels | map(.name) | join(" "))) \(.title) (\(.url)) (by \(.author.login))"'
That would require cleanup to remove insignificant stuff, all but priority label...

[joelim-work]

@DusanLesan I have started a discussion in #1760, but truth be told this idea is attractive enough to me and I have already started working on it.

[DusanLesan]

I like it that way. I hope you keep doing it like so as it is also beneficial to users who dig deeper than released version and release notes

[joelim-work]

No worries. I think this issue isn't needed anymore now that there are milestones so it can be closed.