Current Issue

The release-drafter/release-drafter GitHub action is used to apply semantic versioning to releases automatically drafted with categorized changes based on labels in the relevant pull requests to the release.

With the move to dev branches, the release drafter as it is currently implemented does not work. The release branch no longer has direct pull requests but instead changes automatically cherry-picked from its corresponding dev branch. This means there are no PRs in the release branch to base the release information on.

Proposed Change

All changes to a release branch should occur by the PR into the dev branch having the type:backport label. Therefore, a list of release branch changes can be built off that information. However, the action needs to run against the dev branch to get that which means the dev branch also needs a release point. So, both the dev and release branches need a release and both releases should occur at the same time so the information from the last release branch release is consistent.

The releases should be differentiated by both their release title and tag.

• Release Branch
  • Title: release-v<version>
  • Tag: v<version>
• Dev Branch
  • Title: dev-v<version>
  • Tag: dev-v<version>

This keeps the release branch tag consistent with the tag used today. The titles differentiate the releases in GitHub.

When making a release in GitHub, the dev branch release should be made first and then the corresponding release branch release. The release branch release for the latest release branch (e.g. 202405) should be marked as latest so it is obvious to a consumer what is the latest release for the latest Mu branch in the repo.