Build & Release - Conventional Commits & Changelog
See original GitHub issueThis suggestion may be potentially breaking for the current system but I believe it is worth the initial effort.
Issues/Automation to address:
- force conventional commits (
git-cz
) - generate changelog using commits messages
- easier release
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
, and standard-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:
- All commits to
develop
come with conventional commit messages, strictly related to given modules. - When release time has come, use standard-version to bump package, build changelog, create the tag and publish to
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
All commits in PR are squashed on merge. Please use Conventional Commits when naming your PR.
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.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5
Hi Kamil,
Thanks for suggesting improvements 😃
I am for it. Conventional Commits + a hook for Github checking commit’s format +
commitizen
package.I would put it on hold for the next two releases.
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 Which message do you call “this”?