Skip to content

ci: give release/v0.13 its own release-PR branch prefix - #151

Merged
mrvollger merged 3 commits into
release/v0.13from
ci/release-pr-prefix
Sep 18, 2026
Merged

mrvollger merged 3 commits into
release/v0.13from
ci/release-pr-prefix

Conversation

@mrvollger

Copy link
Copy Markdown
Member

release-plz 0.3.168 locates its open release PR with opened_prs(pr_branch_prefix), which filters on the head branch name only and never on the base branch. Both branches used the default release-plz-, so the run after #150 merged found #132 (main's 0.14.0 release PR), force-pushed the 0.13.1 release onto its branch, and retitled it. #132 has been retargeted to release/v0.13 and is now the correct 0.13.1 release PR.

This sets pr_branch_prefix = "release-v0.13-" on this branch so future runs here create and update only release-v0.13-* PRs, and main's runs (default prefix) never see them. The old-prefix fallback in release-plz is release-plz/, which also does not match.

Merge after #132. Merging this before #132 would make the next run here open a second 0.13.1 PR under the new prefix.

Mitchell R. Vollger and others added 3 commits September 18, 2026 09:19
release-plz matches its open release PR by head-branch prefix only. With
the default prefix a run on this branch took over main's release PR
(#132) and force-pushed 0.13.1 onto it.
hts-sys 2.2.1 did not change htslib; it regenerated bindings with bindgen
0.72, which renamed isize to isize_ and size_t to usize. And the semver
check only needs to stay off until 0.13.1 is the published baseline.
Once 0.14.0 exists, a later 0.13.x would otherwise become GitHub's latest
release, which ft-update and releases/latest/download follow.
@mrvollger
mrvollger merged commit c27254b into release/v0.13 Sep 18, 2026
9 checks passed
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