Introducing milestones 🚩🚩🚩

[joelim-work]

Introduction

This idea was introduced by @DusanLesan in #1669 (comment).

Currently we use a placeholder issue to track upcoming releases, but it is not optimal because:

• It appears in the issue tracker when it is not really an issue.
• It is inconvenient to update whenever a new change is merged.
• It is hard to determine the corresponding release version for a given change.

As a result, I have decided to introduce the use of milestones as part of the management of this project. From now on, pull requests (excluding trivial changes such as chores and dependency bumps) should be linked to a milestone.

The milestone for the next upcoming release is r33.

Labels

As part of this, I have also introduced new labels to indicate different types of changes:

• breaking indicates pull requests that introduce breaking changes.
• new indicates pull requests that add new behavior.
• fix indicates pull requests that fix existing behavior.

Similar to milestones, pull requests should have the appropriate label assigned to them.

Release notes

With the addition of milestones and new labels, release notes can now be generated automatically using the following script:

#!/bin/sh

export GH_PAGER=''
VERSION=r33

list_prs() {
    gh pr list -s merged -S milestone:"$VERSION" -l "$1" \
        --json title,number,author \
        -q "reverse[] | \"- **($2)** \(.title) (#\(.number)) (by @\(.author.login))\""
}

printf '## Changelog\n\n'
list_prs breaking Breaking
list_prs new New
list_prs fix Fix

The only caveat is that pull request titles alone may not be comprehensive enough for the descriptions in the release notes, but for now this can be addressed manually.