-
Notifications
You must be signed in to change notification settings - Fork 5
Description
I would like to propose that we automate the process of (a) managing the version number of this project and (b) releasing new versions of the project to PyPi (with the ultimate goal of expanding these practices to other ESI related projects).
A common solution for these sorts of requirements is one of the various semantic versioning actions available on github; options include things like python-semantic-release and semver-action. These tools typically rely on the use of conventional commit messages to calculate changes to the version number.
There are a couple of workflows we could follow:
-
Most pull requests result in a new release
When we merge a pull request with commits containing the appropriate
feat:orfix:prefixes or aBREAKING CHANGEnote, that will immediately tag a new release on github and push a new release to PyPi. -
Releases only happen explicitly
In this model, pull requests are merged into a development branch, and releases are generated explicitly by merging the development branch into the release branch (typically
main). The version number and PyPi release process is still completely automated, but it's not triggered every time we merge a pull request.
I think I would prefer option 1; part of my goal here is to avoid the problem I've seen in a number of other open source projects in which there has been active development, but no published releases for years, making it difficult to consume the changes introduced into the repository.
If we agree this seems like a good idea, I can submit a pull request with a workflow that we can test out.