lars/giant
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

Auto-bump patch version, tag, and update changelog on merge to master (gitea #50) #71

Merged
lars merged 2 commits from fix/issue-50 into master 2026-08-18 10:50:18 +02:00
Conversation 0 Commits 2 Files Changed 7
+425
lars commented 2026-08-18 10:42:27 +02:00
Owner
Copy Link
Copy Source

Version bumps and release tags were entirely manual; the only CI automation
was sync-version-on-tag, which corrects pyproject.toml if a hand-pushed tag
drifted. This flips that: a new bump-version job (needs the four existing
checks, gated to actual merge commits on master via HEAD^@'s parent count so
direct/squash/rebase pushes are untouched) uses bump-my-version to auto-bump
the patch version when a merged branch didn't already bump it itself, then
generates a changelog entry with git-cliff and pushes a matching vX.Y.Z tag.

git-cliff's cliff.toml is tuned to this repo's plain imperative commit style
(no feat:/fix: prefixes): commits are grouped Added/Fixed/Removed/Changed by
leading verb, "(gitea #N)" is linkified, and merge/[skip ci] commits are
dropped. Per user decision during planning: the changelog generator folds in
@lars's comment on the issue (asking to fold in changelog generation rather
than deferring it), and CHANGELOG.md starts fresh with no backfill of
v0.2.0-v0.3.3.

sync-version-on-tag is left untouched as the safety net for hand-tagging.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Version bumps and release tags were entirely manual; the only CI automation was sync-version-on-tag, which corrects pyproject.toml if a hand-pushed tag drifted. This flips that: a new bump-version job (needs the four existing checks, gated to actual merge commits on master via HEAD^@'s parent count so direct/squash/rebase pushes are untouched) uses bump-my-version to auto-bump the patch version when a merged branch didn't already bump it itself, then generates a changelog entry with git-cliff and pushes a matching vX.Y.Z tag. git-cliff's cliff.toml is tuned to this repo's plain imperative commit style (no feat:/fix: prefixes): commits are grouped Added/Fixed/Removed/Changed by leading verb, "(gitea #N)" is linkified, and merge/[skip ci] commits are dropped. Per user decision during planning: the changelog generator folds in @lars's comment on the issue (asking to fold in changelog generation rather than deferring it), and CHANGELOG.md starts fresh with no backfill of v0.2.0-v0.3.3. sync-version-on-tag is left untouched as the safety net for hand-tagging. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
lars added 1 commit 2026-08-18 10:42:28 +02:00
Auto-bump patch version, tag, and update changelog on merge to master (gitea #50) 5b478d2831 
Version bumps and release tags were entirely manual; the only CI automation
was sync-version-on-tag, which corrects pyproject.toml if a hand-pushed tag
drifted. This flips that: a new bump-version job (needs the four existing
checks, gated to actual merge commits on master via HEAD^@'s parent count so
direct/squash/rebase pushes are untouched) uses bump-my-version to auto-bump
the patch version when a merged branch didn't already bump it itself, then
generates a changelog entry with git-cliff and pushes a matching vX.Y.Z tag.

git-cliff's cliff.toml is tuned to this repo's plain imperative commit style
(no feat:/fix: prefixes): commits are grouped Added/Fixed/Removed/Changed by
leading verb, "(gitea #N)" is linkified, and merge/[skip ci] commits are
dropped. Per user decision during planning: the changelog generator folds in
@lars's comment on the issue (asking to fold in changelog generation rather
than deferring it), and CHANGELOG.md starts fresh with no backfill of
v0.2.0-v0.3.3.

sync-version-on-tag is left untouched as the safety net for hand-tagging.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
lars added 1 commit 2026-08-18 10:42:36 +02:00
Merge branch 'master' into fix/issue-50
CI / Format (ruff format) (push) Successful in 36s
Details
CI / Lint (ruff check) (push) Successful in 37s
Details
CI / Sync project version with tag (push) Has been skipped
Details
CI / Lint (ruff check) (pull_request) Successful in 43s
Details
CI / Type check (ty) (push) Successful in 45s
Details
CI / Format (ruff format) (pull_request) Successful in 39s
Details
CI / Sync project version with tag (pull_request) Has been skipped
Details
CI / Type check (ty) (pull_request) Successful in 39s
Details
CI / Tests (pull_request) Successful in 4m54s
Details
CI / Tests (push) Successful in 5m2s
Details
CI / Bump version, tag, and update changelog on merge to master (pull_request) Has been skipped
Details
CI / Bump version, tag, and update changelog on merge to master (push) Has been skipped
Details
10a57322f9
lars merged commit d0cbcbce80 into master 2026-08-18 10:50:18 +02:00
lars deleted branch fix/issue-50 2026-08-18 10:50:19 +02:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
architecture
bug
Silent/wrong behavior, no crash
 experiment
feature
New feature matching the v0.3 redesign
 investigation
modularity
Making the network genuinely pluggable
 performance
phase2
validation
wontfix
Not being fixed right now
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
lars (Lars Bogner)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lars/giant#71
Delete Branch "fix/issue-50"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?