Closed Helveg closed 1 month ago
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.
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.
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?
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 :)
the only way to reject commits on main
would be with pre receive hooks but they're an enterprise feature?
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
?