Conventional commits: Automated changelog and semantic versioning

[Helveg]

Since we're now adhering to a good semantic versioning scheme, we could benefit from automating it with conventional commits.

@drodarie could you look into ways of enforcing conventional commits, and extracting an automatic changelog from it?

@drodarie, @filimarc I am also a fan of automating the release itself. We could publish a new version for every push to main?

[drodarie]

I think using bump_my_version is good enough to enforce commit for versioning or maybe you have something in mind. In any case, I will investigate ways to extract the changelog but also publishing release on github.

[Helveg]

bump_my_version only changes the version. It doesn't guaranteee that the changes contained within are following semver rules. e.g., nothing stops you from doing bump_my_version major for minor changes.

To automate this, every commit to main should follow conventional commit structure, eg: fix(connectivity): Fixed bug with ...

That way, you can have tools create a nice changelog between commit A and commit B by parsing the structured text, and semver tools can use the same collection of commit messages to calculate whether it should be a patch, minor, or major version change.

With that information an automated release could be created during CI, and published to PyPI.

[drodarie]

Ok I understand what you meant with the commits. It seems difficult to implement but maybe with pre-hooks and Github actions on PR merge? In the meantime, I prepared a github action on this branch for automatic release with an automatic changelog when a new tag is pushed on the main branch. This will also automatically trigger a release on pypi with the original release.yml action which I renamed deploy_pypi.yml. I know that you suggested a release per push on main but without the enforcing on commit, it is difficult to generate a tag. For now, it can serves as an automatic way to deploy after a bump_my_version. I also created a toy project to showcase what the release will look like: https://github.com/drodarie/test_actions

Is it what you envisioned @Helveg?

[Helveg]

there are established tools for it :) a quick Google search for "automatic changelog conventional commits" yields the GitHub repo conventional-changelog for example. I'm sure there's also tools to check if a commit message follows conventional commit format, we just pass/fail CI based on it, and all maintainers should make sure that the merge commits they create for branches follow the format :)

[Helveg]

the only way to reject commits on main would be with pre receive hooks but they're an enterprise feature?