Define commit type, and enhance the `CHANGELOG` format about central HOT 9 OPEN

The best way is to have it on our side to be sure we can't commit something with wrong message. We can use for that grumphp or we can inspire from it to be sure we have something equal for each library. Another thing is to provide a template (if necessary) to pre-fill the commit message.

Regarding the syntax it may be difficult to define the scope so only the prefix as fix: or feat: could be used the scope will be explain in title and commit message after.

As this verification could be bypassed we must add it also on our side. But if we restrict it to be consistent about some format or anything else we should provide an help to use it.

@Pierozi we can add in travis build some verification to be sure it's ok.

from central.

Be careful, generally speaking, preventing someone to commit (even if this is to increase code quality) is considered a bad practice: git concept is commit as often and as quickly as you need.
Additionally, since every commit can be rewritten, we do not need to ensure its consistency while it is on the developer computer.
I'd rather suggest a tool that could be launched manually (by default, it would check every commit between head and upstream branch), for which we can choose the range to analyze.
This tool would then be launched on before push on the client side, and on before receive on server side.

from central.

👍 Beautiful changelog generate, can't agree more !
Did you know if a github bot exist to check the commit message format ?

from central.

Github is a mirror for us, just like Gitlab or Pikacode. So we can add a hook on our own Git server at https://git.hoa-project.net. Thoughts?

from central.

Yup but we use github to accept pull request. same as travis build.
idea is to have PR blocked until commit message fit the expected.

from central.

Yep i like grumphp, that could be enough. Great idea!

from central.

@CircleCode I would highly go on your side.

Should a dry-run mode on hoa devtools:snapshot --only-changelog --dry-run would be adequate?

from central.

🤔 Ok, that could be a part of our Contributor guide, like we ask to run CS before submitting PR.
that's make sense

from central.

I am agree with @CircleCode but this not means we should not provide a kind of tools (helper). We should provide a way to be able to do it on our side. In my case, I prefer to have an error when I try to commit and which explain what I have missed than waiting few weeks for a review and tell me the commit message have a wrong format.

Using Grumphp will force contributors to respect our guideline it's maybe too restrictif, so we should not force people to use it but recommend it. And we should provide an easy way to implement it.

from central.