Releasing
Releases are driven entirely by Git tags — there are no version numbers in the source code. Pushing a tag to main triggers the release workflow automatically.
How it works
- A tag (e.g.
v1.2.0) is pushed tomain - The
release.ymlworkflow triggers - Tests run; if they pass, a self-contained
barebill.exeis published forwin-x64 - A GitHub Release is created with the
.exeattached and release notes auto-generated from merged PR titles
The binary has the tag version stamped into it (visible in About barebill) — no manual .csproj edits needed.
Versioning scheme
barebill uses Semantic Versioning:
| Increment | When to use |
|---|---|
Major (v2.0.0) |
Breaking change to data schema or fundamentally different behaviour |
Minor (v1.1.0) |
New feature shipped to users |
Patch (v1.0.1) |
Bug fix or minor tweak with no new feature |
Tags always use the v prefix: v1.0.0, v1.1.0, v1.0.1.
Step-by-step: creating a release
1. Confirm main is ready
All tests must pass before tagging.
2. Decide the version number
Look at the last tag to determine what changed since then:
Apply the versioning rules above.
3. Create and push the tag
That's it — the release workflow handles everything else.
4. Verify the release
- Go to Actions and confirm the Release workflow passes
- Go to Releases and check that
barebill.exeis attached and the release notes look correct
Fixing a bad release
If a release needs to be pulled:
- Delete the release on GitHub (Releases → Edit → Delete)
- Delete the tag locally and remotely:
- Fix the issue, merge a PR to
main, then re-tag
Release notes
Release notes are auto-generated from merged PR titles since the previous tag. This means your PR titles matter — use the standard prefix format:
| Prefix | Appears under |
|---|---|
feat: |
New Features |
fix: |
Bug Fixes |
docs: |
Documentation |
If a PR title needs to be corrected after merge, edit it on GitHub before tagging — the release notes are generated at tag time.