Description
Feature Request
Motivation Behind Feature
Improve the CHANGELOG readability by including to the git commit messages type and scope.
Feature Description
Change and or improve on our existing git commit message standards.
Background
Currently I been using a modified version of:
- https://karma-runner.github.io/1.0/dev/git-commit-msg.html
- https://www.conventionalcommits.org/en/v1.0.0/
Some of these fit well, reads well, and potentially reduces the message size.
Here is an example list of what I try to follow. It also contains my modification to what I seen in the website above. Also, as a side note, I sometimes even forget or use or use the wrong tag:
feat- new featurefix- bug fixdocs- documentation- This one may not be necessary in
cordova-docsas almost 90% of changes should be doc related, but if we includeblogfor the blog posts, then we could continue to usedocsfor separation.
- This one may not be necessary in
style- formattingrefactor- refactoring of code, variable renaming, etctest- all test related changes (adding, refactoring, deleting)chore- internal tasks (updating dependencies, etc)breaking- to reference a breaking changeci- CI related changes (update, add, delete CI recipes, services, etc.)
Example usage:
feat: add adaptive icon
fix: returning incorrect icon size
docs: adaptive icon usage
style: applied eslint change request
breaking: removed legacy icon support
ci: added xcode 11 to travis
We can also include scoping to increase understanding of where a change might have been and maybe even reduce the size of the message.
Example format: <tag> (<scop>): <message>
Example usage:
docs (android): adaptive icon usage
style (eslint): applied change request
ci (travis): added xcode 11
Remember, the first summary or excerpt line should be limited to 50 chars. The following lines can be how ever long.
Current Guidelines are located here: https://cordova.apache.org/contribute/contribute_guidelines.html
Final Notes
This ticket is to only:
- document some ideas
- explain a format I been using
- to include others for feedback
I am not trying to resolve, change, or enforced some guideline immediately so please do not try push this through ASAP.
At of the time of this posting, I am heavily focused on preparing major releases and hoping to get them out. If someone didn't follow the current or proposed guideline, I do not see any harm has it has not been very strict in the recent years. It current goal is to not block contribution or the major release process. The merger also has a chance to change the commit message when squash & merge.
I don't want to take too much time or effort away form the major release right now.