Skip to content

Apply a forced --version-bump to the version ci publishes - #159

Merged
matt-edmondson merged 2 commits into
mainfrom
fix/152-forced-version-bump
Sep 28, 2026
Merged

matt-edmondson merged 2 commits into
mainfrom
fix/152-forced-version-bump

Conversation

@matt-edmondson

Copy link
Copy Markdown
Contributor

Fixes #152

Problem

ci takes its version from the metadata stage. That version goes into VERSION.md, the packages, the changelog and the tag. MetadataService.UpdateAllAsync called GetVersionInfoAsync without the forced type, so --version-bump only reached ResolveVersionAsync, which is the release gate.

  • A. Last tag v1.2.3 plus one fix, run with --version-bump major: it released 1.2.4.
  • B. No commits since v1.2.3, run with --version-bump minor: metadata computed Skip and kept 1.2.3, the forced gate stayed open, and the release failed with "Failed to create tag".

Change

  • MetadataUpdateOptions.ForcedVersionType is new, and MetadataService passes it to the version calculator.
  • PipelineService.UpdateMetadataAsync(context, versionBump, cancellationToken) now takes the bump, parses it the same way ResolveVersionAsync does, and passes it to metadata. CiCommand passes options.VersionBump to both stages, so metadata and the gate agree.
  • The ApplyResolvedVersion remarks described this divergence as expected. I've reworded them.

This is a breaking change to the public signature of PipelineService.UpdateMetadataAsync. CiCommand was its only caller. I dropped the old two-argument overload instead of keeping it, because leaving it in place would let a caller silently skip the bump again.

Tests (PipelineServiceTests)

  • UpdateMetadataWritesTheForcedVersionBump covers major → 4.0.0, minor → 3.11.0 and patch → 3.10.1 from v3.10.0. It checks the metadata result, Configuration.Version and VERSION.md.
  • ForcedBumpWithNoNewCommitsPublishesTheBumpedVersionThatTheGateApproves covers scenario B: the version is 3.11.0, the gate is open, and metadata agrees with the gate.
  • UpdateMetadataDetectsTheIncrementWhenNoBumpIsForced checks that auto behaves as before.

With the MetadataService change reverted, the major, minor and no-new-commits cases fail. With it, the full suite passes (748/748). This PR merges cleanly with #158 (the #153 fix), which also touches PipelineServiceTests.

🤖 Generated with Claude Code

https://claude.ai/code/session_011EmfGBmvKNA36fj7HFaVgb


Generated by Claude Code

matt-edmondson and others added 2 commits September 27, 2026 18:29
ci takes the version it writes to VERSION.md, packs and tags from the
metadata stage, but only the version gate received the forced bump. A
run with --version-bump major on top of v1.2.3 and a fix released
1.2.4, and a forced bump with no new commits kept 1.2.3 while the gate
stayed open, so the release failed on the existing tag.

Carry the forced type on MetadataUpdateOptions and have the metadata
stage pass it to the version calculator, so metadata and the gate agree.

Fixes #152

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011EmfGBmvKNA36fj7HFaVgb
Drive the ci handler with --version-bump major against a substituted
process runner and assert VERSION.md carries the bumped version. This
covers the CiCommand wiring, which the PipelineService tests cannot
reach.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011EmfGBmvKNA36fj7HFaVgb
@sonarqubecloud

Copy link
Copy Markdown

@matt-edmondson
matt-edmondson merged commit 1ef5ef3 into main Sep 28, 2026
12 checks passed
@matt-edmondson
matt-edmondson deleted the fix/152-forced-version-bump branch September 28, 2026 01:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ci --version-bump major|minor|patch doesn't change the released version, and a forced bump with no new commits fails on an existing tag

1 participant