Skip to main content

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

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.

More information regarding conventional commit types »./conventional-commit-types