I have a small open source package and I'm trying to automate parts of the release life cycle. I am very confused about how to automate version bumps. Here's the relevant information about my version bump procedure.
- I'm working in Python. I define the version hardcoded as the
__init__.pyin the source directory. I've configured
pyproject.tomland Sphinx docs
conf.pyto dynamically read this attribute, so updating
__init__.pyis the only place I need to change it in the source code.
- I make feature branches and merge them into the
mainbranch using GitHub pull requests.
- My current version bump procedure looks like this: After completing work on a feature branch (but before merging the PR) I manually update
CHANGELOG.rstwith the new version and information about the version. I commit these changes.
- Then when all work on the feature is complete (tested, etc.) I merge the PR into
- Next I locally pull
mainand then tag the merge commit on
mainwith the version number and push the tag back to GitHub.
This concludes my version bumping workflow. Pushing the tag triggers a build of my documentation on read the docs and I manually build the code then publish to PyPI. These final steps conclude my full release workflow, but this question is only about the version tagging workflow.
I am trying to automate the last step in the version bump workflow where after the merge I create a tag on the merge commit. One way I could do it is by writing shell commands that read
__version__ out of
__init__.py and create a git tag based on that. I could then embed these commands in a GitHub action that triggers successful PR merges (e.g. pushes to
This will get my job done and I'll start work on it.
However, I'm trying to implement the best packaging/release workflows in this package. I haven't seen any online tutorials/articles etc. advocate for this exact approach. And I haven't been able to find any obvious tools that address this exact workflow*. These two things are major red flags for me.
- Am I trying to implement a bad strategy here?
- Should I be concerned about these red flags?
- Is an obvious well-used tool that does this that I should be using? This would alleviate my concerns.
- If I do spin the shell commands myself, is what I described above a good strategy? Any better suggestions or gotchas to look out for? (I haven't tried this yet, I'll have more info once I give it a shot).
*I have found a lot of packages dedicated to automating version bumping, but none of the ones I've found bump the version based on discovering the version string out of the source code. Many of them scrape the git logs or PR name to determine if the bump is major/minor/patch and then automatically bump the version in source code and create tags automatically. Some even generate a changelog. I have two problems with this approach. (1) I still want to pick the new version and write the changelog manually until I get more comfortable with the automation (or until never) and (2) All of this action would happen before the merge to
main. But in my workflow the tags need to happen on the
main branch. So the tag can't happen in the same "action" as the source code commit.