Open tmarkley opened 2 years ago
Enable release notes drafter
One of the things I've wondered about when making my first few commits is whether some more standardized commit formatting (and enforcement with git hooks) might make the release notes drafting easier, such as specifying the category of change with consistent tags ([Bug]
, [UX]
, [Security]
), etc. While I'm hesitant to add any more friction to the contribution process, it seems like something that might also help make the semver/backporting decisions more automated.
Once a backport PR passes all GitHub CI workflow checks (i.e. build and verify, functional tests, bwc tests, and release artifacts), it should be automatically merged.
šÆ š
Enable release notes drafter
One of the things I've wondered about when making my first few commits is whether some more standardized commit formatting (and enforcement) might make the release notes drafting easier, such as specifying the category of change with consistent tags (
[Bug]
,[UX]
,[Security]
), etc. While I'm hesitant to add any more friction to the contribution process, it seems like something that might also help make the semver/backporting decisions more automated.
Yes great point Josh! I do think that would help with the category automation if we grab the category from the commit. This could also be done by using any categories from the issue that the PR is resolving, but having a standardized format for commits also helps with readability and in some cases discoverability/searchability too.
Every PR should have at least one version label (e.g. v2.1.0) as well as one category label (e.g. bug, new feature, breaking, security, docs, etc.)
Regarding this, I think we could create another label need version
for PRs that are not decided or missed the target version. Use cases could be 1) uncertainty on the version 2) missing target version deadline due to PR reviews or other reasons 3) changing target version. When we launch a new version, we could review all the PRs with both the label of the target version and the label of need version
.
Right now the process for labeling and backporting PRs to ensure changes make it into a particular release is a mostly manual process. Backport PRs are created automatically (if there are no conflicts) but they are still manually reviewed and merged. Generating the release notes is also done manually.
I think we need to discuss opportunities for automating the following:
main
and is targeted for av2.0.1
patch release beforev2.1.0
has been released, the backport to2.x
targetsv.2.0.1
andv2.1.0
.v2.1.0
) as well as one category label (e.g.bug
,new feature
,breaking
,security
,docs
, etc.)breaking
,security
,enhancement
/new feature
,bug
,infrastructure
,docs
,maintenance
,refactor
,tests
bug
label, the PR should target the next patch release AND the next minor release. If the PR is labeled withnew feature
, orenhancement
and there isn't abreaking
label, it should target the next minor release. If the PR is labeled withbreaking
, it should target the next major version release.skip release notes
backport x.x
label(s) should be automatically added.backport
label (to make searching and filtering easier) as well as the corresponding version label(s) from the original PR and issue.skip ci
label.