This section guides you through submitting an enhancement suggestion for Futen, including completely new features and minor improvements to existing functionality. Following these guidelines will help other maintainers to understand your suggestion and find related suggestions.
- Make sure that you are starting from the latest
build/develop. - Read the documentation carefully and find out if the functionality is already covered, maybe by an individual configuration.
Read Conventional Commits Full Specifications for more information on the conventions to follow while committing.
The commit contains the following structural elements, to communicate intent to the other maintainers of the project:
- fix: a commit of the type
fixpatches a bug in your codebase (this correlates withPATCHin Semantic Versioning). - feat: a commit of the type
featintroduces a new feature to the codebase (this correlates withMINORin Semantic Versioning). - BREAKING CHANGE: a commit that has a footer
BREAKING CHANGE:, or appends a!after the type/scope, introduces a breaking API change (correlating withMAJORin Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. - types other than
fix:andfeat:are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommendsbuild:,chore:,ci:,docs:,style:,refactor:,perf:,test:, and others. - footers other than
BREAKING CHANGE: <description>may be provided and follow a convention similar to git trailer format.
Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.