Maintainer's Tasks
This document provides a reference of the key tasks maintainers within the Server State ecosystem have to fulfill.
Conventional Commits
Make sure that every change has a conventional commit associated with it.
Having a conventional commit for every change enables our tools to automatically
generate the release notes and the next released version. Thus, if a branch has
valid and correct conventional commit messages, you can go ahead and merge it by
rebasing it onto the main branch.
Otherwise, you may have to squash and merge using a valid conventional commit message. In the end, the only important thing is that every change that's relevant for the following type of version (for example, a feature or a breaking change) or the next version's release notes have a valid conventional commit for it in the main branch.
Merge commits appear not to get used (to their full extent). Therefore, if, for merging a Pull Request, you need a new conventional commit message, use Squash and Merge
For some contributions, it just isn't practical to have one mergeable branch per
change. For example, refactoring might, in the process, also fix a lot of old
issues. In that case, you can squash and merge using the "biggest" applicable
conventional commit (for example, feat: Big Refactoring), while putting
Closes: #issuenumber for every closed issue into the commit's footer. So even
though fixing a bug would, initially, be a fix, the feature of an overall
refactoring (with possibly a few breaking changes) outweighs that, and fixing a
bug is just a side-effect.
