Git(hub) Workflow¶
This section will explain the specifics regarding to git
and github
.
Commit message rules¶
We use Conventional Commits as standard for our commit messages. With this standard commit messages are human and machine readable so that the change-log creation and versioning can be automated based on keywords. Commit messages will be checked in the CI pipeline.
If you submit non-compliant commit messages we will need to ask you to fix them. So we
highly recommend you to set pre-commit
up.
If you set up pre-commit
as described above you already have the commit-msg
hook
installed which will check your commit message for compliance else you can run:
$ nox -s setup_pre_commit
Development workflow¶
We have no dedicated development branch so all changes are expected to be submitted and
merged into master
. Merging into master
is only allowed after all CI tests
succeeded. Pull requests must be merged with a merge commit.
Bugfixes are also expected to be merged into master
. But if they are critical the
next release will be much sooner.
If the pull request has many small commits the maintainer may use a squash merge to keep the change-log cleaner. Of cause the squash commit-message must follow the aforementioned commit message rules!
Release workflow¶
When enough changes and additions or time important fixes have accumulated on the
master
branch its time for a new release. The exact time is subject to the
judgment of the maintainer(s).
To trigger a new release you have to manually start the Release new version
workflow
for the master
branch form the Actions
tab of the Github repository. The
workflow will run the full current test suit first. After that it will also run the full
test suit of the previous version and when the test suit fails it will look for a commit
declaring BREAKING CHANGES. If none is found the workflow will fail. After success the
workflow will automatically bump the version counter based on semantic versioning and
conventional commits, update the change-log, create a new git tag, build the
package + wheel and push them to PyPI. At last a Github release is created with the built
source as assets.
Note: As all changes are merged into
master
only the current released version is supported and will receive bugfixes. Bugfixes for older versions are not planned.