fix: skip stable update prompt for newer prereleases

[LIghtJUNction]

When AstrBot runs a prerelease/dev version and update checks ignore prereleases, the updater can compare against the latest stable release instead. If the current prerelease is already newer than that stable release, AstrBot should not show an update prompt that effectively points users back to an older stable version.

Modifications / 改动点

• Added a shared prerelease-version detector in RepoZipUpdator.

• Reused that detector when filtering prerelease releases from update candidates.

• Skipped stable update prompts when the current prerelease/dev version is already newer than or equal to the selected stable release.

• Added a regression test for the non-prerelease update-check path.

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

$ uvx ruff format --check .
477 files already formatted

$ uvx ruff check .
All checks passed!

$ uvx ty check astrbot/core/zip_updator.py tests/test_updator_socks.py
All checks passed!

$ uv run pytest tests/test_updator_socks.py -k prerelease
1 passed, 28 deselected, 3 warnings in 166.34s

$ uv run pytest tests/test_updator_socks.py
29 passed in 98.97s

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。
  No new feature is added in this PR.

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The prerelease vs stable comparison at the end of check_update runs compare_version(current_version, tag_name) >= 0 twice when current_is_prerelease is true; consider consolidating the logic into a single comparison branch to avoid redundant checks and make the flow easier to follow.
• The _is_prerelease_version helper currently checks only for simple alpha|beta|rc|dev suffixes; if you expect more complex prerelease patterns (e.g., multiple segments or additional labels), consider tightening or documenting the regex assumptions to avoid misclassification of future tags.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The prerelease vs stable comparison at the end of `check_update` runs `compare_version(current_version, tag_name) >= 0` twice when `current_is_prerelease` is true; consider consolidating the logic into a single comparison branch to avoid redundant checks and make the flow easier to follow.
- The `_is_prerelease_version` helper currently checks only for simple `alpha|beta|rc|dev` suffixes; if you expect more complex prerelease patterns (e.g., multiple segments or additional labels), consider tightening or documenting the regex assumptions to avoid misclassification of future tags.

## Individual Comments

### Comment 1
<location path="astrbot/core/zip_updator.py" line_range="273-274" />
<code_context>
             logger.error("未找到合适的发布版本")
             return None

+        if current_is_prerelease and not self._is_prerelease_version(tag_name):
+            if self.compare_version(current_version, tag_name) >= 0:
+                return None
+
</code_context>
<issue_to_address>
**question:** The prerelease-specific guard appears redundant with the general version comparison below.

If `VersionComparator` uses semver semantics, a prerelease like `1.0.0-beta` already compares as lower than `1.0.0`, so this branch doesn’t change the result of the final `compare_version(...) >= 0` check. If you’re trying to support a different behavior (e.g. preferring a newer prerelease over the latest stable), it may be clearer to encode that explicitly in the comparison logic or in a separate branch that actually differs from the final condition, rather than duplicating it here.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

question: The prerelease-specific guard appears redundant with the general version comparison below.

If VersionComparator uses semver semantics, a prerelease like 1.0.0-beta already compares as lower than 1.0.0, so this branch doesn’t change the result of the final compare_version(...) >= 0 check. If you’re trying to support a different behavior (e.g. preferring a newer prerelease over the latest stable), it may be clearer to encode that explicitly in the comparison logic or in a separate branch that actually differs from the final condition, rather than duplicating it here.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	astrbot-docs	0a8fb37	Commit Preview URL Branch Preview URL	Jun 28 2026, 07:26 PM

[gemini-code-assist]

Code Review

This pull request refactors the version update check by introducing a helper method _is_prerelease_version to identify prerelease versions and adds a corresponding test case. Feedback on the changes points out a redundant conditional block in check_update that performs an identical version comparison to a subsequent check, which can be safely removed along with its unused current_is_prerelease variable.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

This conditional block is completely redundant and can be safely removed.

Why is it redundant?

1. Identical Inner Condition: The inner condition self.compare_version(current_version, tag_name) >= 0 is exactly the same as the subsequent check on line 277.
2. Logic Flow:
   • If self.compare_version(current_version, tag_name) >= 0 is True, the function will return None anyway (either here or on line 278).
   • If it is False, neither block will trigger, and it won't return None.
   • Therefore, the outer check current_is_prerelease and not self._is_prerelease_version(tag_name) has no effect on the outcome.

Version Comparison Behavior

In VersionComparator.compare_version, the numeric parts are compared first. For example, with current_version = "v4.26.0-dev" and tag_name = "v4.25.6", the numeric parts are [4, 26, 0] and [4, 25, 6]. Since 26 > 25, it immediately returns 1 (greater than) without comparing prerelease tags. Thus, the standard check on line 277 already correctly returns None and skips the update.

Removing this block simplifies the logic and improves maintainability. Please also remove the unused current_is_prerelease variable definition on line 254 to avoid linter warnings.

[gemini-code-assist]

If the redundant block on lines 273-275 is removed, the current_is_prerelease variable becomes unused. Removing it prevents potential linter warnings (such as Ruff's F841).