Open c-wygoda opened 2 months ago
i've become a friend of https://commitizen-tools.github.io/commitizen/ lately which helps with using https://www.conventionalcommits.org/en/v1.0.0/ by providing
Would love to hear thoughts on using it? @mindflayer @jsignell
I changed the merge flow to trigger tagging, it's always 0.0.0, but with the date and time added, i.e. v0.0.0+240509-181509, as that doesn't break PEP440 and gives us new tags.
Tags then trigger a Github release, docker build and deploy: https://github.com/stapi-spec/stapi-fastapi/actions/runs/9021637647
If no-one objects until 2024-05-16, I'll remove all tags from before today, as they are somewhat randomly manually created.
Thanks for writing this up. I don't have strong opinions other than agreeing with the general principle that the easier it is to release the more often we will actually do it. I think semver is a fine place to start and then we can revisit at a later time if we dislike it for this project for some reason.
If we enforce squash merge it might make it easier to keep the commit messages consistent without introducing the burden of consistent commit messages on contributors.
I am fine with deleting the old tags.
i've become a friend of https://commitizen-tools.github.io/commitizen/ lately which helps with using https://www.conventionalcommits.org/en/v1.0.0/ by providing
* a small CLI to create commits from simple questions * pre-commit hooks to validate commit messages * CLI to bump version with automatically updating CHANGELOG.md from the commits going into the new version
Would love to hear thoughts on using it? @mindflayer @jsignell
Lovely, I'll propose to use it in my team.
stapi_fastapi.constants:STAPI_VERSION
. also should either do semantic versioning - but need to decide how to manage that, i.e. conventional commits? - or switch to datetime based tags for now.