Since this is a new project with few users, we're starting simple with a tag-based release process that leverages semantic versioning to control and version releases.
The intention is for maintainers of this repository to prepare for a release using these steps. If it becomes burdensome, it can be further automated.
Review a diff between the prior release tag and the current commit. The purpose of this review is to observe if there would be any breaking changes introduced between releases if a release was made. Based on your findings, select a new version number in accordance with standard semver practices.
If the scope of the changes is large, build and install the driver and run some local tests to ensure it works as designed. This local testing may need to include both the 32 and 64 bit versions of the driver. Whether or not testing is required (or testing of different bitnesses) is left to the discretion of the maintainer performing the release.
Select the semantic version of your release, then push a tag of
the form vX.Y.Z, based on the version number you selected
in step 1. Observe the github action workflow for the release
process to ensure it completes successfully.
Observe that a draft (non-public) release has appeared at the top of the repositories release list. This release is visible only to maintainers of the repository. Modify the autogenerated changelog to make it more readable or provide a summary of changes if required. This is also an opportunity to inspect or test the installers built by the github workflow for the release process (if desired).
Once you have reviewed the draft (non-public) release and found it to be ready for the user community, mark the release as ready (public). This completes the release process.