Open kgajowy opened 4 years ago
Hi Kamil,
Thanks for suggesting improvements :)
force conventional commits (git-cz)
I am for it. Conventional Commits + a hook for Github checking commit's format + commitizen
package.
generate changelog using commits messages
I would put it on hold for the next two releases.
easier release
This is related to your proposed change to the branch flow, automatic versioning etc. I would put it on hold for the next two releases.
Rationale: AskQL is a new repo and I expect its number of issues, number of contributors, size of milestones etc. to change significantly for the time being. If we introduce a process, we should first know what issues we want to solve. While the characteristics of the repo and the behavior pattern of the contributors still change, I think it's too early to introduce processes which have heavy impact on the workflow or tie us up to a specific procedure.
The only change I would introduce soon is a standard for all the commit messages, which makes our log history much cleaner and meaningful.
Conventional Commits sounds like a great choice, a hook for checking the message format would help enforce this and the commitizen
package would make it easier and more convenient for developers.
@mhagmajer , what are your thoughts?
@mhagmajer , any thoughts?
Agree with all this except for the merge strategy - let's enforce one PR per feature/bug - it makes reviewing easier and faster
Agree with all this except for the merge strategy - let's enforce one PR per feature/bug - it makes reviewing easier and faster
@mhagmajer Which message do you call "this"?
This suggestion may be potentially breaking for the current system but I believe it is worth the initial effort.
Issues/Automation to address:
git-cz
)A helper for newcomers to this standard - would be useful for new contributors to reduce the initial effort to get the submission
right
.In addition to
commitizen
package,cz-conventional-changelog
, andstandard-versions
packages, it's quite easy to make an automated way of generating changelog (based on commit messages) and publishing new versions.The flow could look like:
develop
come with conventional commit messages, strictly related to given modules.npm
Example of the output here
It may seem to be a little complicated but trust me - it's great automation made in an easy way. It reduces the need to manually manage
What's new
.PS
There is no point in using conventional commits everywhere, as long as the PR is squashed (only the first one will be used). Please consider allowing to not squash if a PR touches multiple modules/areas and the changes/commits are correctly separated.