Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix ClawHub Versions page should sort releases by SemVer descending [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78023•Fetched 2026-05-06 06:17:49
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
2
Author
BenKalskyBenKalsky
Participants
BenKalskyBenKalskyclawsweeper[bot]clawsweeper[bot]
Timeline (top)
closed ×1commented ×1

The ClawHub skill Versions list appears to be ordered by publish/create date rather than semantic version precedence.

On the wordpress-api-pro Versions page in mobile view, the list currently shows:

  1. v3.2.0 · 3/28/2026
  2. v2.1.0 · 3/16/2026
  3. v3.0.1 · 3/16/2026
  4. v3.0.0 · 3/2/2026
  5. v2.0.2 · 3/2/2026

This makes v2.1.0 appear above v3.0.1, even though 3.0.1 is the newer version by SemVer.

Root Cause

The Versions page is used for downloading older releases and reviewing changelog/security status. Users expect the list to reflect version precedence, especially when multiple releases are published close together or backfilled.

RAW_BUFFERClick to expand / collapse

Summary

The ClawHub skill Versions list appears to be ordered by publish/create date rather than semantic version precedence.

On the wordpress-api-pro Versions page in mobile view, the list currently shows:

  1. v3.2.0 · 3/28/2026
  2. v2.1.0 · 3/16/2026
  3. v3.0.1 · 3/16/2026
  4. v3.0.0 · 3/2/2026
  5. v2.0.2 · 3/2/2026

This makes v2.1.0 appear above v3.0.1, even though 3.0.1 is the newer version by SemVer.

Expected behavior

When rendering release/version history, sort by SemVer descending by default:

  1. v3.2.0
  2. v3.0.1
  3. v3.0.0
  4. v2.1.0
  5. v2.0.2

If a version string is invalid or non-semver, fall back to createdAt/publish date as a secondary sort key.

Actual behavior

Versions with the same/similar date appear to be sorted by publish/create date or insertion order instead of semantic version precedence.

Why this matters

The Versions page is used for downloading older releases and reviewing changelog/security status. Users expect the list to reflect version precedence, especially when multiple releases are published close together or backfilled.

Suggested fix

Use SemVer-aware sorting for valid version strings, descending, with a stable fallback:

  1. valid SemVer desc
  2. publish/create date desc for ties or invalid versions
  3. stable id/order fallback if needed

Context

Observed on mobile in the ClawHub public skill page for wordpress-api-pro, under the Versions tab.

extent analysis

TL;DR

Implement SemVer-aware sorting for version strings in descending order, with a fallback to publish/create date for ties or invalid versions.

Guidance

  • Review the current sorting algorithm to identify why it's prioritizing publish/create date over semantic version precedence.
  • Update the sorting logic to first sort by valid SemVer in descending order.
  • For versions with the same SemVer or invalid version strings, use publish/create date as a secondary sort key in descending order.
  • Consider adding a stable id/order fallback for edge cases where the above sorting keys are insufficient.

Example

No specific code example is provided due to the lack of implementation details, but the sorting logic could resemble a function that takes a list of versions and returns them sorted based on SemVer and then date.

Notes

The suggested fix assumes that the version strings are mostly SemVer compliant. If there are many non-SemVer version strings, additional handling may be necessary to ensure correct sorting.

Recommendation

Apply the workaround by implementing SemVer-aware sorting, as it directly addresses the issue of incorrect version ordering and provides a clear, expected behavior for users.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

When rendering release/version history, sort by SemVer descending by default:

  1. v3.2.0
  2. v3.0.1
  3. v3.0.0
  4. v2.1.0
  5. v2.0.2

If a version string is invalid or non-semver, fall back to createdAt/publish date as a secondary sort key.

#api#configuration error#environment variable#network issue#logging issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix ClawHub Versions page should sort releases by SemVer descending [1 comments, 2 participants]