Closed redeboer closed 1 year ago
Perhaps worth to consider the conventions listed here: https://github-activity.readthedocs.io/en/stable/#splitting-prs-by-tags-and-prefixes
Settled for the following:
Commit type | Repository label | Description |
---|---|---|
FEAT |
![]() |
New features added |
ENH |
![]() |
Improvements and optimizations of existing features |
FIX |
![]() |
Bug has been fixed |
BREAK |
![]() |
Breaking changes to the API |
BEHAVIOR |
![]() |
Changes that may affect the framework output |
DOC |
![]() |
Improvements or additions to documentation |
MAINT |
![]() |
Maintenance and upkeep improvements |
DX |
![]() |
Improvements to the Developer Experience |
So an example of a commit would be:
BEHAVIOR: add non-negative assumptions to mass symbols
which would get this PR label:
@spflueger, do you think these cover our PR/commit types?
Angular conventional commit messages have "breaking change" as an additonal marker independent of the commit type https://www.conventionalcommits.org/en/v1.0.0/#summary . That seems more flexible to me. Im not aware it this can be combined nicely with the release drafter.
We used to follow these conventional commit types and allowed appending !
(which was done somewhat arbitrarily). I would say this now becomes BREAK
.
The major change in the suggested scheme (https://github.com/ComPWA/.github/issues/7#issuecomment-1209318257) is that the types of 'breaking changes' are clearer. BREAK
is a change to the API that might break existing scripts and therefore require a bump in the minor version. (More mature libraries do this through slow, progressive deprecations, but we are still in 0.x.x
releases). BEHAVIOR
is less severe, but still needs to be clearly signaled to the release notes. It's also important because we provide physics libraries, where sometimes a certain formalism tweak is introduced that may affect physics results, but is not an API change. This was missing so far.
See Commit conventions and ComPWA repository labels.
refactor
andchore
are too ambiguous.ci
is collecting many meanings since 'local' CI, GitHub Actions, and deployment have become more synchronised (throughtox
).Need at least labels for:
docs
folder, to docstrings in the source code, or to any other explanatory files.