# Versioning
# Semantic Versioning
Solarix uses traditional semantic versioning to indicate the compatibility of each committed changed.
# Commit Message Syntax
Solarix uses the Conventional Commits specification, which defines how a proper commit message should be formatted.
A commit message consists of a title, body, and footer. The title is the only required line and it MUST have a type
and subject
field. It also usually has a scope
, which defines which aspect of the project the commit applies to:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The body can contain any necessary text to support the commit. The footer is typically where relationships are mentioned, such as closed issue, affected merge request, impacted branch, etc.
# Breaking Changes
Any commit that introduces a breaking change should be formatted in either one of two ways:
- An explicit
!
character between thetype(subject)
and colon separator within the title:fix(ui)!: changes ALL THE THINGS
- The text
BREAKING CHANGE:
and two new lines should prepend the commit message:BREAKING CHANGE:\n\nfix(ui): changes ALL THE THINGS
# Examples
# Feature
feat(dashboard): add 'user' model
Everyone loves a good dashboard. Now users can enjoy it.
Closes #15.
- Increments
MINOR
version due tofeat
type. - Adds the title to the generated changelog under
Features
header. - Links to issue
#15
.
# Fix
fix(dashboard): remove unintended access for Satan
Sure, everyone loves a good dashboard, but we can't let just ANYONE use it...
Closes #666.
- Increments
PATCH
version due tofix
type. - Adds the title to the generated changelog under
Bug Fixes
header. - Links to issue
#666
.
# Breaking Change
fix(ui)!: changes ALL THE THINGS
- Increments
MAJOR
version due to!
breaking change indicator. - Adds the title to the generated changelog.
# Commit Message Linting
The Commitlint package is enabled to assist in generating properly formatted commit messages.
See the .commitlintrc.js file for the full ruleset.
TIP
JetBrains users may want to check out this plugin.
# Git Hooks
The Husky package is used to perform Git hook-related tasks, the most important of which is linting. When attempting a commit a git hook performs linting via commitlint
as mentioned above, checking the validity of your commit message. Any errors are indicated in the console and the commit is cancelled.
See the .huskyrc.js example file for the configuration.
# Commit Message Generation
For step-by-step assistance creating a valid commit message you may use the included Commitzen package. Instead of git commit
or committing via your IDE, run the yarn commit
command. This will open the Commitizen CLI UI which will walk you through a series of questions to build up the full, valid commit message.
TIP
Power-users will probably find it faster to manually write commit messages, but Commitizen is a handy way to get used to the necessary syntax.
← Projects Contributing →