create a more automated release process

[12rambau]

At the moment the release process is not very automated and quite slow. looking at the release name I realize we always end up creating minor increments (0.11 -> 0.12 -> 0.13) and very few patches even though we put lots of efforts correcting bugs and unexpected behavior.

I want to know if it's desirable to use a more robust and automatic release process to speed up our release pace.

In the libs I maintain (sepal-ui, pygadm, qutree, opensartoolkit among others), I respect the conventional commits which makes it possible to use the commitizen-tools pre-commit hooks and ensure a very fast releasing process.

With this tools the process would be the following:

• commit with commitizen compatible messages e.g. "docs: correct typo" or "fix: avoid overlapping of headers"
• once we need a release, execute cz bump. cz will detect the increment based on the commit types and update version value everywhere specified in the conf. finally it creates a tag.
• push the bump commit to github
• create a new release + tag (to get the automatic changelog) and let the release.yml file take care of the rest

bonus: it can create an up to date changelog file at each bump.

if a commit is not using a conventional commit, it's simply ignored from increment detection and changelog.md

[drammock]

I'm generally pro-automation. Our releases at MNE-Python are even slower/more manual, so I'm interested in these ideas and am happy to field-test / guinea-pig them here. Also interested in whether @jarrodmillman and @choldgraf have other release automation practices they want to stump for?

[choldgraf]

I'm definitely a fan of automation, though in my experience, enforcing things like "conventional commits" is hard to do in an open source community that doesn't have highly-aligned workflows, and can be a source of tension when people don't follow the process. It's also a barrier to contributions if people have to download and learn a new tool to make a commit. E.g., the GIF in the commitzen-tools repo makes it look like you need to answer like 5 questions for every commit, that feels cumbersome to me.

Where do you think is the biggest pain point of our technical release process right now? To summarize it from my perspective, these are the essentials:

• Bump the version in __init__.py
• Add a changelog (I use github-activity which similarly categorizes based on commit message)
• Push to main
• Create a "release" in the GitHub UI that points to the commit you just pushed.

In our process, we do also require adding a dev0 after bumping the version - I'd be more than happy to stop that practice if that would help streamline things.

Either way I also suggest that we make our release guidelines be more based on "time" than "significance". E.g.:

• If it has been more than a month since the last release, or if we have made significant changes since the last release, then anybody is encouraged to make a new release.

[12rambau]

I'm definitely a fan of automation, though in my experience, enforcing things like "conventional commits" is hard to do in an open source community that doesn't have highly-aligned workflows, and can be a source of tension when people don't follow the process. It's also a barrier to contributions if people have to download and learn a new tool to make a commit. E.g., the GIF in the commitzen-tools repo makes it look like you need to answer like 5 questions for every commit, that feels cumbersome to me.

small update on this very topic:

• as a contributor, you don't need to install commitizen as it's checked in the pre-commit
• you don't need to use the "cz commit" command simply use a descriptor in a normal message. The pre-commit hook tells you what to do if you make a typo or forget one

• in our case, we don't even need to enforce it, as we squash all PR we simply need to respect the convention in the PR merge. and it can be added to a PR template (check the naming of your PR blablabla).
• all the above-mentioned steps can be replaced by "cz bump" -> "git push" which is to me way simplier
• note that we can also make prerelease with "cz bump --preprelease N"

If it has been more than a month since the last release, or if we have made significant changes since the last release, then anybody is encouraged to make a new release.

agreed

[choldgraf]

FWIW, I'm happy to give something a shot and see if it makes people's lives easier!

[drammock]

+1 to switch to calendar-based (not feature-based) releases. FWIW MNE-Python has a 4-month release cadence, matplotlib has 6-month cadence. IMO anything less than 3 is crazy unless releases are very automated.

[12rambau]

I played a bit with github actions triggers and I think I converged to a working workflow. I created a test repository here: https://github.com/12rambau/test_autogithubrelease

to make a new release I do the following:

cz bump
git push 
git push origin <tag_name>

the only missing piece is the "back to dev" commit. according to this thread: commitizen-tools/commitizen#662 you still need to have at least 1 commit before bump the "dev".

advantages:

• 3 commands, nothing else to remember
• automatic semver versionning
• we still get the same changelog

what do you think ?