fix: release tag sorting

[benlife5]

@anguyen-yext2 pointed out that our getLatestTag function sorts alphabetically instead of by semver

Tested by running the function in node and returning the full list of versions. Confirmed that the old code output
'v1.0.0-beta.0', 'v0.0.9', 'v0.0.8', 'v0.0.7', while the new code output 'v1.0.0-beta.0', 'v0.0.66', 'v0.0.65', 'v0.0.64',....

Also updates the initial version for alpha/beta/rc releases to be .1

[coderabbitai]

Walkthrough

The pull request modifies the release utility script to adjust prerelease version numbering and improve tag retrieval logic. The getVersionChoices function now generates prerelease suffixes ending in .1 instead of .0 when incrementing from alpha, beta, or release candidate states. The getLatestTag function replaces its previous tag sorting mechanism with a git command that uses semantic version ordering (git tag --sort=-v:refname), selecting the first result and applying trim operations to the output. These changes refine how version strings are generated and how the latest tag is identified during the release process.

Pre-merge checks and finishing touches

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'fix: release tag sorting' directly and clearly describes the main change: fixing the tag sorting logic in getLatestTag to use semantic versioning instead of alphabetical sorting.
Description check	✅ Passed	The description is directly related to the changeset, explaining the bug fix (alphabetical vs semver sorting), providing test results, and noting the secondary change to prerelease version numbering.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch tag-sorting

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

scripts/releaseUtils.ts (2)

148-162: Confirm intent around new -alpha.1/-beta.1/-rc.1 behavior

The new alpha/beta/rc branches now start the next patch prerelease at .1 (e.g. 1.2.3-alpha.2 → 1.2.4-alpha.1), which matches the PR description for continuing from an existing prerelease. However, the rc-minor/beta-minor/alpha-minor and corresponding *-major options still use semver.inc(..., "pre*"), which will continue to produce *.0 as the initial prerelease when starting from a stable version.

If your goal is for all new alpha/beta/rc trains (including the preminor/premajor flows) to start at .1, you may also want to adjust those branches (e.g., by post‑processing the *.0 result or doing a second prerelease bump).

---

185-192: Harden getLatestTag for empty output and types

Using git tag --sort=-v:refname is a solid way to get semver‑ordered tags, but there are a couple of small robustness points here:

• If the repo has no tags, result.stdout.trim().split(/\n/).filter(Boolean)[0] yields undefined even though the function is typed as Promise<string>.
• On Windows, splitting only on \n may leave a trailing \r on lines.

You can make this safer and keep the Promise<string> signature by normalizing the value and handling CRLF:

 export async function getLatestTag(): Promise<string> {
-  // -v:refname is a descending semver sort
-  const result = await run("git", ["tag", "--sort=-v:refname"], {
-    stdio: "pipe",
-  });
-
-  return result.stdout.trim().split(/\n/).filter(Boolean)[0];
+  // -v:refname is a descending semver sort
+  const result = await run("git", ["tag", "--sort=-v:refname"], {
+    stdio: "pipe",
+  });
+
+  const latest =
+    result.stdout
+      .trim()
+      .split(/\r?\n/)
+      .find(Boolean) ?? "";
+
+  return latest;
 }

logRecentCommits will still treat an empty string as “no tag”.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6a08909 and 507b185.

📒 Files selected for processing (1)

• scripts/releaseUtils.ts (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: call_unit_test / unit_tests (18.x)
• GitHub Check: call_unit_test / unit_tests (20.x)
• GitHub Check: semgrep/ci