You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

No actionable comments were generated in the recent review. 🎉

Walkthrough

Release tooling updated to promote prerelease patch bumps to stable by stripping prerelease suffix, added tag-detection and an interactive release confirmation, updated changelog links and added a 16.5.0 entry, and extended tests to cover the new behaviors and edge cases. (34 words)

Changes

Sequence Diagram(s)

sequenceDiagram
    participant Rake as Rake(:release)
    participant Resolver as VersionResolver
    participant Changelog as CHANGELOG.md
    participant Git as Git
    participant User as User (stdin)

    Rake->>Resolver: resolve_version_input(current_gem_version, version_input)
    Resolver->>Git: version_tagged?(monorepo_root, candidate)
    Git-->>Resolver: tagged / not tagged
    Resolver-->>Rake: compute_target_gem_version(...)
    Rake->>Changelog: extract_changelog_section(final_version)
    Changelog-->>Rake: section content / nil
    Rake->>User: confirm_release!(version) (prompt)
    User-->>Rake: y / n
    alt confirmed
      Rake->>Git: create tag / push / perform release steps
    else aborted
      Rake-->>User: abort release
    end

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐇 I nibbled the rc tail clean and bright,
Promoted the patch to steady light,
I asked for a “y” before tags take flight—
Hop, tag, push, and a carrot for tonight. 🥕

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 @coderabbitai help to get the list of available commands and usage tips.}

Review: Fix release script — require changelog, fix RC version computation

This is a solid, focused fix for two real bugs that caused the 16.5.0 release to ship without a changelog or GitHub release. The changes are clean, well-scoped, and follow the existing codebase patterns.

What works well

• compute_target_gem_version patch fix — correctly mirrors gem bump --version patch behaviour (stripping the pre-release suffix rather than incrementing the patch segment). The comment explaining why is helpful.
• require_changelog_section! refactor — follows the established handle_version_policy_violation! / allow_override pattern consistently. The error message is actionable and includes the env-var escape hatch.
• Call order — changelog check now runs before validate_release_version_policy!, which is the right priority: fail fast on the most user-correctable issue.
• CHANGELOG.md — 16.5.0 section added with accurate links; the [unreleased] base updated to v16.5.0.

One gap worth considering

The minor and major branches in compute_target_gem_version don't have the pre-release guard (see inline comment). If gem bump --version minor on 1.0.0.rc.0 behaves differently from 1.1.0 (the computed value), the same category of bug can resurface for those bump types. Worth verifying and either adding the guard or adding a comment confirming the intentional difference.

Minor nit

The error message in require_changelog_section! hardcodes the escape-hatch syntax as rake release[VERSION,false,true]. The false for dry_run might mislead someone who intended a dry run — rake release[VERSION,true,true] is equally valid. A small tweak like rake release[VERSION,DRY_RUN,true] would be clearer.

Overall this is good to merge once the minor/major pre-release question is resolved (or documented as intentional).

Greptile Summary

This PR fixes two bugs in the release automation that caused the 16.5.0 stable release to go out without a CHANGELOG entry or GitHub release. The changes are surgical and correct.

• compute_target_gem_version (patch + pre-release): When the current version has a pre-release suffix (e.g., 16.5.0.rc.0) and patch is requested, the old code incremented the patch component to 16.5.1, but gem bump --version patch actually strips the suffix to produce 16.5.0. The fix adds a pre-release guard so the stable version is returned directly, matching the actual gem-release gem behaviour.
• require_changelog_section! (hard stop): The former warn_changelog_missing only printed a message and let the release continue. The renamed require_changelog_section! now calls the existing handle_version_policy_violation! helper, which aborts unless RELEASE_VERSION_POLICY_OVERRIDE=true is set, consistent with the rest of the version policy enforcement.
• CHANGELOG.md: Adds the missing ### [16.5.0] section (stable-promotion note), updates the [unreleased] comparison base to v16.5.0, and inserts the [16.5.0] diff link between the RC and stable tags.

Confidence Score: 5/5

• Safe to merge — both fixes are logically correct, narrow in scope, and consistent with existing patterns in the codebase.
• The two core fixes (compute_target_gem_version and require_changelog_section!) directly address the described root causes and are verified against the surrounding helper functions (parse_gem_version_components, handle_version_policy_violation!, extract_changelog_section). The only open items are non-blocking style suggestions (empty-section edge case, missing comments on minor/major pre-release behaviour).
• No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["rake release[version, dry_run, override]"] --> B[resolve_version_input]
    B --> C[validate_requested_version_input!]
    C --> D[compute_target_gem_version]

    D --> E{Is pre-release\nversion?}
    E -- "yes + patch bump\n(NEW: e.g. 16.5.0.rc.0)" --> F["Strip suffix → 16.5.0\n✅ was: 16.5.1"]
    E -- "no + patch bump" --> G["Increment patch\n16.5.0 → 16.5.1"]
    E -- minor/major --> H["Bump minor/major\n(unchanged)"]

    F --> I
    G --> I
    H --> I

    I["require_changelog_section!"] --> J{Section\nexists?}
    J -- "yes" --> K[validate_release_version_policy!]
    J -- "no + allow_override" --> L["⚠️ Warn and continue\n(RELEASE_VERSION_POLICY_OVERRIDE=true)"]
    J -- "no + no override" --> M["❌ abort release\n✅ was: just a warning"]

    L --> K
    K --> N[Run gem bump / npm publish / GitHub release]

_{Reviews (1): Last reviewed commit: "Fix release script: require changelog se..." | Re-trigger Greptile}

Review

The two root-cause fixes are correct and well-targeted:

• compute_target_gem_version (patch + pre-release) — stripping the suffix instead of incrementing the patch number matches gem bump behaviour and directly fixes the 16.5.0 miss. ✓
• resolve_version_input untagged detection — using an untagged changelog version rather than silently falling back to "patch" is the right fix. ✓
• confirm_release! prompt — a good guardrail addition; the dry-run bypass is sensible. ✓

I've left four inline comments covering:

1. version_tagged? uses stale (local) tags — validate_release_version_policy! is the authoritative gate, so this isn't a safety hole, but a comment or explicit fetch_tags: true would prevent confusing diagnostics. (line 529)

2. resolve_version_input edge case when changelog_version < current_version and untagged — the new branch fires even for a lower changelog version, which would produce a confusing abort message downstream. Narrowing the guard to == current_version matches the stated intent. (line 549)

3. confirm_release! lets the user proceed without a changelog entry — the prompt warns but doesn't enforce; the gem gets published but the GitHub release silently doesn't, which is the exact failure mode the PR intends to prevent. Worth either a second confirmation or an abort. (line 390)

4. "minor"/"major" bumps from a pre-release are not adjusted — lower priority since most RC promotions use "patch", but worth a comment documenting the intended semantics. (line 210)

The most actionable of these is #2 (narrowing the <= to ==) and #3 (stronger enforcement when changelog is missing).

Review: Fix release script — RC version computation and changelog gate

Overall this is a solid, well-scoped fix. The root causes are correctly identified, the changes are minimal, and the new specs cover the key cases. A few things worth addressing:

1. version_tagged? relies on stale local tags

version_tagged? passes fetch_tags: false to tagged_release_gem_versions. It is called from resolve_version_input, which runs before validate_release_version_policy! fetches tags. If the local tag cache is stale, version_tagged? could return false for a version that has already been released, causing the release task to proceed for an already-published version.

Consider either fetching tags inside version_tagged?, or adding a comment explaining why the downstream validate_release_version_policy! (which does fetch) is a sufficient safety net.

2. confirm_release! has no specs

The new confirm_release! reads from stdin but is not exercised by any spec. Worth adding cases for: abort on non-'y' input, abort on nil (EOF), and the two changelog-present vs missing display paths.

3. No runtime warning for minor/major from pre-release

The comments in compute_target_gem_version explain the footgun (16.5.0.rc.0 + minor produces 16.6.0, not 16.5.0), but there is no runtime signal. A puts warning in those branches would surface the surprise without blocking anything.

4. Removing warn_changelog_missing silences the dry-run changelog warning

The old warn_changelog_missing ran unconditionally, including during dry runs. The new confirm_release! is skipped on dry runs (unless is_dry_run). This means rake release[patch,true] no longer warns about a missing changelog section. Consider printing changelog status even on dry runs (without the prompt) to preserve pre-flight visibility.

5. Minor: has_changelog is a string, not a boolean

extract_changelog_section returns a String or nil. Naming the variable has_changelog and using it as a boolean works in Ruby but is slightly misleading. Using !!extract_changelog_section(...) would make the intent explicit.

CHANGELOG note

The 16.5.0 compare link (v16.5.0.rc.0...v16.5.0) will 404 until v16.5.0 is tagged. Expected once the release lands, just noting it for anyone reviewing before that.

Verdict

The core logic fixes are correct. Issues 1 and 4 are the most impactful: a stale-tag false-negative in version_tagged? could trigger an accidental re-release, and silently dropping the dry-run changelog warning reduces pre-flight visibility.

Review: Fix release script — RC version computation and changelog enforcement

The two root-cause fixes are correct and well-reasoned. The Gem::Version comparison (== for untagged same-version) and the patch -> strip-prerelease behavior both match gem-release semantics, and the new tests cover the key cases clearly.

A few things worth addressing before merging:

1. version_tagged? only checks local tags (inline comment on line 538)
It calls tagged_release_gem_versions(fetch_tags: false), so the check can give a false negative if the local clone has not fetched recently. The downstream validate_release_version_policy! (which does fetch) will still abort, but the error message will be a confusing version-policy violation rather than the expected 'falling back to patch' path. The simplest fix is fetch_tags: true here -- it adds one extra git fetch --tags but makes the resolution logic self-consistent.

2. Silent abort on non-interactive stdin (inline comment on line 416)
stdin.gets returns nil when stdin is closed (piped empty input, /dev/null, etc.), which silently aborts with just 'Release aborted.' -- no indication that the cause was a missing TTY. A one-line nil check with a better message would save future debugging.

3. Confirmation blocks automated pre-release runs (inline comment on line 760)
confirm_release! fires for every non-dry-run release, including prereleases. If a scripted/CI pre-release workflow exists or is added later, it will hang or abort at the prompt. Worth deciding explicitly whether prereleases should also be gated -- and if not, adding '|| is_prerelease' to the guard.

4. confirm_release! has no tests (inline comment near line 202 in spec)
The function has branching logic and an abort path but zero test coverage. Stubbing stdin is straightforward in RSpec.

Positive notes:

• extract_changelog_section returning nil (not empty string) for empty sections is a good correctness fix -- Ruby's empty string is truthy, so the old version had a silent bug where an empty changelog section appeared as present.
• The test for 'untagged == current' vs 'tagged == current' cleanly documents the new behavior.
• Comments on minor/major bump behavior from a pre-release are clear and prevent the same confusion from recurring.

Code review findings for this PR (3 issues + minor notes): (1) BEHAVIORAL REGRESSION - dry runs no longer show changelog warning. warn_changelog_missing was unconditional but confirm_release! is skipped for dry runs, so users doing rake release[patch,true] preflight checks get zero changelog feedback now. Suggest splitting display from interactive prompt. (2) DOUBLE TAG FETCH - version_tagged? calls tagged_release_gem_versions with fetch_tags:true, then validate_release_version_policy! does the same, causing two git fetch --tags round-trips. Consider accepting fetch_tags: keyword in version_tagged? and passing false there. (3) STYLE INCONSISTENCY - version_tagged? uses positional args while every other helper in release.rake uses keyword args, making argument-order mistakes easy. Suggest: version_tagged?(monorepo_root:, version:). Minor/non-blocking: (a) dry-run skip for confirm_release! is in the caller with no comment explaining why - add a comment; (b) test name 'falls back to patch bump when changelog version is older than current and untagged' is misleading since version_tagged? is never called in that path. Overall the fix is correct and test coverage is solid.