Build & Release - Conventional Commits & Changelog

[kgajowy]

This 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:

1. All commits to develop come with conventional commit messages, strictly related to given modules.
2. 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.

[czerwinskilukasz1]

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.

[czerwinskilukasz1]

@mhagmajer , what are your thoughts?

[czerwinskilukasz1]

@mhagmajer , any thoughts?

[mhagmajer]

Agree with all this except for the merge strategy - let's enforce one PR per feature/bug - it makes reviewing easier and faster

[czerwinskilukasz1]

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"?