Repository navigation
feat(version-file): follow release branches - #328
Merged
Automaat merged 4 commits intoOct 7, 2026
Merged
Conversation
version-file derived the dev/preview entry and the active branch list purely from published GitHub releases, so during a branch-cut-to-publish cycle every consumer saw latest+1: kuma releasing 3.0 still reported the next version as 2.15 and release-3.0 stayed invisible to backport and release-issue automations for the whole cycle. Discover the repo's release-X.Y branches and, when the newest one is ahead of every published release line, derive the preview release label and active branches from it. Without such a branch the output is unchanged. Signed-off-by: Marcin Skalski <skalskimarcin33@gmail.com>
A draft release for the version being prepared (kong-mesh has one right now) produced a versions.yml entry that masked its own release branch: latestReleased parsed the draft's version, the branch compared equal and was skipped, so the preview fell back to latest+1 exactly in the window the fix targets. Derive the comparison base from published releases only, and degrade to the release-only output when the branch lookup fails instead of failing the daily regeneration. Signed-off-by: Marcin Skalski <skalskimarcin33@gmail.com>
With a draft for the version being prepared the draft-only line still built a versions.yml entry whose branch then collided with the newly detected release branch: active-branches listed release-3.0 twice and yaml mode emitted two entries claiming release 3.0.x. Skip lines that have no published release and guard the branch insertion against duplicates. The core assembly is now a pure function with tests covering the draft window. Signed-off-by: Marcin Skalski <skalskimarcin33@gmail.com>
Automaat
requested review from
lobkovilya and
lukidzi
and
a balanced review from Copilot
and removed request for
a team
October 6, 2026 15:03
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Prerelease handling is inconsistent, and malformed release branch versions can panic regeneration.
Review effort: Balanced
Findings: 2
Open (2)
What changed in this PR
Updates version-file generation to follow unreleased release-X.Y branches.
Changes:
- Derives preview versions and active branches from release branches.
- Skips draft-only release lines and handles missing published releases.
- Adds paginated branch discovery and unit tests.
| File | Description |
|---|---|
cmd/release-tool/version_file.go |
Adds branch-aware version assembly. |
cmd/release-tool/version_file_test.go |
Tests version and branch selection. |
cmd/internal/github/graphql.go |
Adds paginated branch retrieval. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
A semver-prerelease tag published without GitHub's prerelease flag slipped into the comparison base, and a branch name whose numeric parts exceed semver's range panicked the regeneration. Apply the same semantic-version prerelease check to the comparison base and parse branch versions with an error return, skipping invalid ones. Signed-off-by: Marcin Skalski <skalskimarcin33@gmail.com>
bartsmykla
approved these changes
Oct 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
kumahq/kuma and Kong/kong-mesh are releasing 3.0 (
release-3.0cut from master), but every release automation still computes the next version as 2.15:version-filederives the dev/preview entry fromlatestReleased.IncMinor()(2.14.5 → 2.15.x) and--active-branchesonly lists branches that already have a published release line, sorelease-3.0is invisible for the whole branch-cut→publish cycle. Consumers (release-issue automations, backport workflows, docs dev label) all read these generated files.Implementation information
GQLClient.ReleaseBrancheslists repo branches via the REST API (paginated).assembleVersions(extracted, unit-tested) detects the newestrelease-X.Ybranch ahead of every published release line. When one exists, the preview entry'sReleasecomes from that branch (3.0.x) and--active-branchesincludes it before the default branch. Without one, output is unchanged (preview = latest+1).release: 3.0.xtwice,release-3.0twice in active-branches).release: 3.0.xand listrelease-3.0inbaseBranchPatterns; byte-identical output on a control repo without release branches; branch pagination exercised (>100 branches on both).Unsettled question from review: only the single newest unreleased branch is included. If two release branches exist with no published release (e.g.
release-3.1cut before 3.0.0 ships), the older one stays invisible. Not observed in practice; happy to extend if wanted.Supporting documentation
.github/workflows/release.yaml(release-tool version-file)pkg/release/version.goMinorReleaseVersions