Bazel: Fix prerelease filtering with same-release-line scoping

[v-HaripriyaC]

What are you trying to accomplish?

Fixes the P2 behavioral gap in Bazel's prerelease filtering identified in the versioning audit. Previously, when a user was on a prerelease (e.g., 35.0-rc1), Dependabot would propose updates to any newer prerelease including unrelated ones (e.g., 36.0-alpha.1). This creates noise and potentially harmful update PRs — particularly for the protobuf module on BCR which regularly publishes -rc1/-rc2 prereleases.

The fix adds same-release-line scoping so that:

• Stable users never see prereleases (preserved)
• Prerelease users only see prereleases for the same base version + stable upgrades
• Unrelated prereleases from different release lines are excluded

Anything you want to highlight for special attention from reviewers?

This logic is implemented at the Bazel ecosystem level (not in common/) for the following reasons:

1. Interface mismatch - Common's PackageLatestVersionFinder operates on Array[PackageRelease]; Bazel works with raw Array[String] version lists
2. Bazel doesn't inherit from it - Bazel::UpdateChecker has its own fetch_latest_version — common's filter_prerelease_versions is not in the call chain
3. Risk - Changing common affects 20+ ecosystems; this is a safe, isolated fix │
   The approach is modeled after Bun/npm's related_to_current_pre? pattern — compares current.release == candidate.release to scope prerelease inclusion to the same base version.

How will you know you've accomplished your goal?

spec scenarios validate the behavior:

1. Stable user → prereleases excluded, latest stable returned
2. Prerelease user → stable upgrade proposed (35.0-rc1 → 35.0)
3. Stable user with only prereleases newer → returns nil
4. Prerelease user with unrelated prereleases → unrelated excluded
5. Prerelease user with same-line prerelease only → returns 36.0-rc2
6. Prerelease user with only unrelated prereleases newer → returns nil
7. No current version → prereleases excluded, latest stable returned

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have reviewed my changes.

[Copilot]

Pull request overview

This PR adjusts the Bazel ecosystem’s version-selection logic to avoid proposing unrelated prerelease updates when a dependency is currently pinned to a prerelease, while still allowing stable upgrades. It implements “same release line” scoping for prereleases in Bazel::UpdateChecker and adds a comprehensive spec matrix to validate the new behavior.

Changes:

• Add prerelease filtering to Bazel’s update selection so prerelease users only consider prereleases on the same base release line (plus stable releases).
• Reorder filtering so prerelease filtering happens before ignored-version filtering, and add defensive handling for malformed registry versions.
• Add targeted specs for stable vs prerelease current versions, unrelated prereleases, nil current version, logging, and .bcr.X stability behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
bazel/lib/dependabot/bazel/update_checker.rb	Adds same-release-line prerelease filtering and adjusts filter ordering / validation in Bazel’s latest-version selection.
bazel/spec/dependabot/bazel/update_checker_spec.rb	Adds scenario coverage validating the prerelease scoping, logging behavior, malformed versions, and .bcr.X interactions.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[kbukum1]

@v-HaripriyaC , if you can confirm the following feedback then it is ready.

1. update_checker.rb — misleading comment. "BCR registry data is well-formed; correct? guard is defensive only" contradicts reality — the guard is load-bearing (you test not_valid!!! flowing through). Reword to reflect that it actively filters malformed versions.
2. version.rb — dedupe the affix-stripping. self.correct? and initialize both hardcode .sub(/\.bcr\.\d+$/, "").sub(/^v/i, ""). Extract one private normalizer so they can't drift.
3. Add a test for 35.0-rc1.bcr.1 (prerelease + .bcr combo). The trailing-only strip makes this resolve to a prerelease — currently unverified, so behavior could silently break.
4. Add a test for being on a .bcr version with newer prereleases available — that path isn't exercised.

Everything else (the scoping logic, filter ordering, correct? override existence, the broad scenario coverage) is correct and should not change.

[v-HaripriyaC]

bazel-prerelease-fix-walkthrough.md
walkthrough of the inputs and outputs

[v-HaripriyaC]

@v-HaripriyaC , if you can confirm the following feedback then it is ready.

1. update_checker.rb — misleading comment. "BCR registry data is well-formed; correct? guard is defensive only" contradicts reality — the guard is load-bearing (you test not_valid!!! flowing through). Reword to reflect that it actively filters malformed versions.
2. version.rb — dedupe the affix-stripping. self.correct? and initialize both hardcode .sub(/\.bcr\.\d+$/, "").sub(/^v/i, ""). Extract one private normalizer so they can't drift.
3. Add a test for 35.0-rc1.bcr.1 (prerelease + .bcr combo). The trailing-only strip makes this resolve to a prerelease — currently unverified, so behavior could silently break.
4. Add a test for being on a .bcr version with newer prereleases available — that path isn't exercised.

Everything else (the scoping logic, filter ordering, correct? override existence, the broad scenario coverage) is correct and should not change.

done!