fix(ci): follow higher prerelease line when one already exists

[TimeToBuildBob]

Problem

The dev-release workflow computes next_base by bumping latest_stable by the configured RELEASE_LINE (defaulting to patch). It then looks for existing prereleases matching that specific version. But it never checks whether a prerelease for a newer version already exists.

Concretely: latest_stable = v0.13.2, RELEASE_LINE = patch → next_base = 0.13.3. The workflow only looks for v0.13.3bN tags, ignoring that v0.14.0b1 already existed. This caused the scheduled run to draft v0.13.3b1 and v0.13.3b2 — stale patch prereleases behind the already-in-flight minor release line.

Fixes #1307.

Fix

After computing next_base, find the highest existing prerelease tag across all versions. If it's for a version newer than next_base, use that version's base instead — continuing the in-flight release line rather than starting a stale one.

latest_stable=v0.13.2, next_base=0.13.3, highest_prerelease=v0.14.0b1
→ hp_base=0.14.0 > 0.13.3 → next_base overridden to 0.14.0
→ next_tag=v0.14.0b2 ✓

Test plan

• Verify the preflight script logic manually: tag a repo with v0.13.2 + v0.14.0b1, run the script with RELEASE_LINE=patch — next_tag should be v0.14.0b2
• Trigger the workflow via workflow_dispatch to confirm it produces v0.14.0b2 next
• Delete the stale v0.13.3b1 / v0.13.3b2 draft releases that were incorrectly created

[greptile-apps]

Greptile Summary

This PR fixes a bug in the dev-release workflow where the biweekly scheduler would start a fresh stale patch prerelease (e.g. v0.13.3b1) even when a higher in-flight prerelease line (e.g. v0.14.0b1) already existed, because it only searched for prereleases matching the newly-computed next_base.

• New logic: After computing next_base, the workflow now finds the globally highest existing prerelease tag. If its base version is strictly greater than next_base, it overrides next_base with that version — ensuring the in-flight release line is continued rather than a stale one started.
• Version comparison: Uses sort -V | tail -1 to determine the higher of hp_base vs next_base, with an explicit equality guard so equal versions fall through to the existing prerelease-search logic unchanged.

Confidence Score: 4/5

Safe to merge; the fix correctly redirects the scheduler to continue an in-flight minor/patch prerelease line rather than creating a stale lower one.

The bash logic handles the primary scenario and all edge cases: hp_base < next_base (no override), hp_base == next_base (equality guard prevents override), hp_base > next_base (override then falls into existing last-prerelease search). The sort -V comparison and git tag --sort=-version:refname both agree on version ordering for standard semver-style tags. A stale prerelease tag whose base has since been stabilized will never be picked up because hp_base would then be less than or equal to the new next_base. The score reflects modest risk from touching release-tagging automation.

No files require special attention; the only changed file is the preflight step of the CI workflow.

Important Files Changed

Filename	Overview
.github/workflows/dev-release.yml	Adds a 16-line bash block after next_base is computed to detect an already-in-flight prerelease line at a higher version and override next_base accordingly; logic is sound and edge cases are handled correctly.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Get latest_stable tag] --> B[bump_version → next_base]
    B --> C{highest_prerelease\nexists?}
    C -- No --> E
    C -- Yes --> D{hp_base >\nnext_base?}
    D -- No --> E[prerelease_pattern for next_base]
    D -- Yes --> F[Override: next_base = hp_base]
    F --> E
    E --> G{last_prerelease\nfor next_base?}
    G -- Yes --> H[since_ref = last_prerelease\nnext_tag = vNb+1]
    G -- No --> I[since_ref = latest_stable\nnext_tag = vNb1]
    H --> J[commits_since_ref == 0?]
    I --> J
    J -- Yes → skip --> K[should_release=false]
    J -- No → CI OK --> L[should_release=true, push next_tag]

Loading

_{Reviews (1): Last reviewed commit: "fix(ci): follow higher prerelease line w..." | Re-trigger Greptile}

[TimeToBuildBob]

This PR is ready for merge:

• ✅ All CI checks pass
• ✅ Greptile review: 4/5 — "Safe to merge; the fix correctly redirects the scheduler to continue an in-flight minor/patch prerelease line rather than creating a stale one."

The 4/5 score reflects general caution about release automation, not a specific code issue. No inline feedback to address. @ErikBjare, this just needs your merge.