fix(releases): Sort by build number & code in semver when resolving in next release

[srest2021]

fixes REPLAY-803

When detecting regressions via compare_version we are comparing the build codes. However, we are not ordering by build code or number in any other instances of semver ordering, which leads to inconsistent behavior.

For example, when determining the "next" release to resolve an issue by, we get the greatest semver version with an arbitrary build code--say the greatest semver in our project is 2.0.0 (10) and we pick 2.0.0 (8) arbitrarily. Say we later see that issue appearing in 2.0.0 (9). We would mark it as a regression because 2.0.0 (9) > 2.0.0 (8) according to compare_version, even though the greatest semver in our project was 2.0.0 (10) and it should not be marked as a regression.

In this PR we add build number and code to the semver ordering. We mimic the behavior of compare_version by ordering on build code and build number (aka numeric build code). This will make our semver ordering consistent when viewing sorted releases lists, resolving issues, and detecting regressions.

Build code ordering in compare_version, DESC (largest to smallest):

1. alphanumeric builds (compared lexicographically)
2. numeric builds (compared numerically)
3. no build

Before

Sorting by semver sorts the version but not the build number, which stays in the order in which it was created.

Screen.Recording.2026-01-23.at.10.12.21.AM.mov

Resolving in the next release, where the greatest semver release is 4.0.0 (13) instead arbitrarily picks 4.0.0 (10). You can also see that "The current semver release" in the dropdown has arbitrarily picked 4.0.0 (12).

Screen.Recording.2026-01-23.at.10.21.46.AM.mov

After

Sorting by semver now sorts the build numbers as well -- alphanumeric builds on top, then numeric builds, then no build.

Screen.Recording.2026-01-23.at.10.09.14.AM.mov

Resolving in the next release, where the greatest semver release is 4.0.0 (13), now correctly picks 4.0.0 (13). "The current semver release" in the dropdown also correctly references 4.0.0 (13).

Screen.Recording.2026-01-23.at.10.26.02.AM.mov

[linear]

REPLAY-803 Build code considered when detecting regressions but not when finding the current release version

[srest2021]

We don't need to actually merge this but just thought I'd include it for a better picture of how compare_version actually works when detecting regressions. Here we can see that numeric builds are compared numerically and adding any letters makes the comparison lexicographic. We also see that alphanumeric builds are greater than numeric builds, and any build is greater than no build.