chore: configure v3 beta prereleases and document migration-guide policy - #1199
Merged
Merged
Conversation
main now takes v3 breaking changes incrementally. Without this, the first `!:`/BREAKING CHANGE commit would make release-please jump straight to a stable 3.0.0 tag instead of an alpha/beta line. Mirrors the same config already used on release/v3 (see #1042).
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe release configuration enables beta prereleases for the root package and uses Assessment against linked issues
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Closed
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@release-please-config.json`:
- Around line 5-6: Update the release configuration containing "prerelease" and
"prerelease-type" to add "versioning": "prerelease", ensuring breaking releases
generate beta-suffixed versions such as 3.0.0-beta.1.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 5f577727-2252-4615-9e38-a13dadfa4392
📒 Files selected for processing (1)
release-please-config.json
Comment on lines
+5
to
+6
| "prerelease": true, | ||
| "prerelease-type": "beta", |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
jq -e '
.packages["."] as $pkg
| (($pkg.versioning // .versioning // "default") == "prerelease")
and ($pkg.prerelease == true)
and ($pkg["prerelease-type"] == "beta")
' release-please-config.json >/dev/nullRepository: supabase/supabase-swift
Length of output: 161
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- release-please-config.json ---'
cat -n release-please-config.json
printf '%s\n' '--- related release-please files and references ---'
git ls-files | rg '(^|/)(release-please|\.release-please|package\.json|README|CHANGELOG)' || true
rg -n --hidden --glob '!**/.git/**' 'versioning|prerelease-type|prerelease|release-please' . || trueRepository: supabase/supabase-swift
Length of output: 2544
🌐 Web query:
Release Please customizing.md prerelease versioning prerelease-type versioning prerelease
💡 Result:
In Release Please, prerelease functionality is managed through a combination of a versioning strategy and configuration settings in your manifest or action configuration [1][2][3]. To implement prerelease versioning, you must use the prerelease versioning strategy [1][4]. This strategy works in conjunction with the prerelease boolean configuration setting [1][2]. When prerelease is set to true, Release Please will create prerelease versions (e.g., 1.0.0-alpha.1) [2][5]. If this setting is false (the default), a prerelease version will not be created, even if the versioning strategy is selected [1][2]. You can further customize the prerelease behavior using the prerelease-type configuration option [2][5]. This option allows you to define the prerelease identifier (e.g., "beta" or "alpha") [2][5]. When prerelease-type is set, the versioning strategy will incorporate this value into the prerelease part of the version string (e.g., bumping 1.2.1 to 1.3.0-beta) [1][4]. These configurations can be applied at the root level or per-package level in your release-please-config.json or manifest configuration [3]. When using the CLI, these can also be passed as flags: --prerelease and --prerelease-type [6][7]. Summary of key settings: - Versioning Strategy: Set to prerelease to enable this logic [1][4]. - prerelease (boolean): Must be true for any prerelease versions to be generated [2][5]. - prerelease-type (string): Defines the prefix for the prerelease portion of the version (e.g., "beta") [2][5].
Citations:
- 1: https://github.com/googleapis/release-please/blob/HEAD/docs/customizing.md
- 2: https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md
- 3: https://github.com/marketplace/actions/release-please-action
- 4: googleapis/release-please@95a6568
- 5: https://github.com/googleapis/release-please/blob/refs/heads/main/docs/manifest-releaser.md
- 6: https://github.com/googleapis/release-please/blob/main/docs/cli.md
- 7: https://github.com/googleapis/release-please/blob/HEAD/docs/cli.md
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- manifest ---'
cat -n .release-please-manifest.json
printf '%s\n' '--- release instructions around versioning ---'
sed -n '1,110p' RELEASE.mdRepository: supabase/supabase-swift
Length of output: 2431
Set "versioning": "prerelease" before merge.
"prerelease": true marks the release as a prerelease but does not select prerelease version generation. Without "versioning": "prerelease", a breaking change can produce 3.0.0 instead of 3.0.0-beta.1.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@release-please-config.json` around lines 5 - 6, Update the release
configuration containing "prerelease" and "prerelease-type" to add "versioning":
"prerelease", ensuring breaking releases generate beta-suffixed versions such as
3.0.0-beta.1.
Coverage Report for CI Build 31615915420Coverage increased (+0.6%) to 84.582%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions7 previously-covered lines in 1 file lost coverage.
Coverage Stats
💛 - Coveralls |
Contributor
|
The following capabilities are marked
These may have been renamed, removed, or never registered. Please update the capability matrix. |
Adds the policy to AGENTS.md and a CI job that enforces it: any PR
whose title or commits carry a breaking-change marker ('!' or
BREAKING CHANGE:) must touch a file under docs/migrations/.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/migration-guide-check.yml:
- Around line 59-61: Update the CHANGED_FILES calculation in the migration-guide
check to include only added or modified files from the git diff, excluding
deleted paths, before applying the existing docs/migrations/*.md pattern match.
Preserve the current validation behavior for migration guides that are added or
updated.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: fb658e49-9791-401a-b034-366c05f21271
📒 Files selected for processing (2)
.github/workflows/migration-guide-check.ymlAGENTS.md
grdsdev
changed the title
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Keep the migration-guide policy in AGENTS.md as guidance, but remove the automated check — enforce via review instead.
grdsdev
changed the title
o-santi
approved these changes
Aug 12, 2026
7 tasks
grdsdev
added a commit
that referenced
this pull request
Aug 13, 2026
release-please's default versioning strategy ignores `prerelease` and `prerelease-type` entirely -- those fields are only read by the `prerelease` versioning strategy, which only activates when "versioning": "prerelease" is set. Without it, a major bump produces a plain X.0.0 tag instead of X.0.0-beta.N. PR #1201 is live proof: it computed 3.0.0, not 3.0.0-beta.1, despite the fields added in #1199. That 3.0.0 proposal is itself spurious: an earlier commit described the conventional-commits breaking-change footer in prose, and the literal text was picked up by release-please's own scan even though nothing breaking shipped. main is force-push protected, so history can't be rewritten to remove it; folding it into an ordinary patch release is the supported way to clear it. Release-As: 2.55.1
3 tasks
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
3 participants
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.
What
"prerelease": true, "prerelease-type": "beta"torelease-please-config.jsononmain.docs/migrations/.Why
v2.55.0 (#1163) was the last v2 release.
mainnow starts taking v3 breaking changes incrementally (small PRs, not a big-bang merge ofrelease/v3).Prerelease config: without it, the first
!:/BREAKING CHANGE:commit merged tomainwould make release-please's next PR jump straight from 2.55.0 to a stable 3.0.0 tag. With it, that commit instead produces3.0.0-beta.1, then3.0.0-beta.2, etc. — mirroring the config already proven onrelease/v3(see the now-closed #1042,chore(release/v3): release 3.0.0-beta.1). Flipprereleaseback tofalsewhen v3 is ready to go stable.Migration guide policy: landing v3 breaking changes piecemeal makes it easy for a change to merge without documented migration steps. Documented in AGENTS.md as a review-time expectation; there's no CI guard for it (dropped — enforced via review instead).
Context
release/v2(cut at thev2.55.0tag)