📓 Guideline: Conventional Commits

[almostearthling]

Conventional Commits

Beginning with version 2.0.0 of When, the Conventional Commits standard is used, with some more specific suggestions for the parts of the commit message. These suggestions, which might change and improve throughout time, are similar to the ones used in whenever.

Commit messages should have the following format:

<type>[(optional scope in round brackets)]: <description>

[optional body]

[optional footer(s)]

In particular, for the type, use:

• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix
• amend: An amendment not related to a bug and that does not constitute a feature
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• deps: Modifications that are related to a dependency change or upgrade
• temp: A transient commit that generally produces non working code

Scopes that can be used are:

• main: the main controlling program
• ui: the user interface in general
• tasks: something related to task items
• conds: something related to condition items
• events: something related to event items
• items: something related to more than one type of items
• log: modifications to the logging system
• config: changes in the configuration functionality
• strings: changes that only affect the text that is used in the logs or as output
• i18n: changes affecting localization/internationalization

For the footer part, the breaking change directive should be BREAKING-CHANGE: (with a hyphen) followed by a space and the reason why it is breaking. The <description> does not begin with a capital letter.