Skip to content

ci: deterministic v3.6.x release versioning#51

Closed
lacraig2 wants to merge 1 commit into
mainfrom
fix/versioning-v3.6
Closed

ci: deterministic v3.6.x release versioning#51
lacraig2 wants to merge 1 commit into
mainfrom
fix/versioning-v3.6

Conversation

@lacraig2

Copy link
Copy Markdown
Contributor

Problem

The first merge-to-main release published v3.3.11reecetech/version-increment mis-derived the base from the legacy v3.5.x-beta tag history, producing a version lower than the prior v3.5.33-beta.

Fix

Replace version-increment with a deterministic step in the aggregate job: the next version continues the v3.6.x line — next = highest existing v3.6.* patch + 1, or v3.6.1 when none exist. Monotonic and predictable. To start a new minor line later, bump MAJOR_MINOR.

  • First release after this lands → v3.6.1, then v3.6.2, v3.6.3, …
  • Release gating unchanged (publish only on push; dev_* → prerelease).

Verified the logic locally against live tags → computes v3.6.1.

The merge-to-main release produced v3.3.11 -- reecetech/version-increment
mis-derived the base from the legacy v3.5.x-beta tags (a regression vs the
old beta line). Replace it with a deterministic step that continues the v3.6.x
line: next = highest existing v3.6.* patch + 1, or v3.6.1 when none exist.
Monotonic and predictable; bump MAJOR_MINOR to start a new minor later.
@lacraig2

Copy link
Copy Markdown
Contributor Author

Closing in favor of the simpler approach: version-increment reads tags and ignores the -beta semver prereleases, so it bumped from the highest non-prerelease tag (v3.3.10 → v3.3.11). Pushing a bare v3.6.0 tag makes that the base → next release is v3.6.1, then forward. No workflow change needed.

@lacraig2 lacraig2 closed this Jun 19, 2026
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.

1 participant