doc (git): commit message standards

[erisu]

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 feature
• fix - bug fix
• docs - documentation
  • This one may not be necessary in cordova-docs as almost 90% of changes should be doc related, but if we include blog for the blog posts, then we could continue to use docs for separation.
• style - formatting
• refactor - refactoring of code, variable renaming, etc
• test - all test related changes (adding, refactoring, deleting)
• chore - internal tasks (updating dependencies, etc)
• breaking - to reference a breaking change
• ci - 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.

[erisu]

@brodybits here is the ticket about what I been doing for git commit messages. Again as I said in the ticket, I am only posting it right now for informational purpose and including others.. I am not seeking for immediate change or enforcement. I want to focus on the major releases right now.

[erisu]

Here are the tags broken into release version types. IMO

Major Releases

• breaking

Major & Minor Release

• feat

Major, Minor & Patch Releases

• fix
• refactor
• test
• docs
• blog
• chore
• style
• ci