We use this format to make the automatic generation of the changelog for all packages easy.
We follow the Conventional Commits Specification message pattern that leads to human and machine-readable commit messages. They are easy to follow when looking through the project history. Thus, please ensure that you follow the rules for commits and merge requests:
<type>([<package>]<scope>): <subject>
Don't worry, to make it easy for all of us, we added an action to our Github Repo which validates the given commit message
Must be one of the following:
| Type | Description | Affects Version |
|---|---|---|
| feat | Introduces a new feature to the codebase. | MINOR |
| fix | Patches a bug in your codebase. | PATCH |
| docs | Documentation only changes. | (no change) |
| style | Do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc), not CSS styles. | (no change) |
| refactor | Neither fixes a bug nor adds a feature. | (no change) |
| perf | A code change that improves performance. | (no change) |
| test | Adding missing tests. | (no change) |
| chore | Changes to the build process or auxiliary tools and libraries such as documentation generation. | (no change) |
This is optional but it is recommended to set the affected package when the change is assignable to exactly one package.
In our mono repo we need to distinct which package is affected by the change. Hence, in addition to the scope we added the name of the package in front of the scope.
You are able to use one or none of the following packages:
| Package Name | Affected Package |
|---|---|
| elements | @inovex.de/elements |
| elements-angular | @inovex.de/elements-angular |
| elements-react | @inovex.de/elements-react |
| storybook | @inovex.de/elements-storybook |
The subject contains a succinct description of the change:
- Use the imperative, present tense: "change" not "changed" nor "changes".
- Do not capitalize first letter.
- Do not place a period
.at the end. - Describe what the commit does, not what issue it relates to or fixes.
- Be brief, yet descriptive - we should have a good understanding of what the commit does by reading the subject.
A breaking change always affects the MAJOR version number in the next release. This should rarely be used. You should always talk to the team members about such a change. If you only deprecate things, it is no breaking change.
To document breaking changes, use a multiline commit message, which will be taken as the main commit message for the whole MR when squashed.
Here is an example:
type([package]scope): brief description
BREAKING CHANGES: <description of breaking changes without a new line at the beginning>