Update Cursor version resolution to avoid latest lagging behind newly published patch releases.

2025-12-25 20:11:13 -04:00
parent 9e18ec27f9
commit 23c508079c
2 changed files with 100 additions and 12 deletions
@@ -95,6 +95,25 @@ The `update-cursor.sh` script provides:
 - **x86_64 AppImage Download**: `https://api2.cursor.sh/updates/download/golden/linux-x64/cursor/{version}`
 - **aarch64 AppImage Download**: `https://api2.cursor.sh/updates/download/golden/linux-arm64/cursor/{version}`

+### Version pointers / "channels"
+
+Cursor exposes a few redirect-style pointers that may not always move in lockstep:
+
+- **`.../cursor/latest`**: “promoted” latest build for that channel. This can lag a new release during phased rollout / promotion.
+- **`.../cursor/{major.minor}` (e.g. `.../cursor/2.2`)**: latest patch within that major.minor line. This can point to a newer build earlier than `latest`.
+
+Concrete example (this has happened in practice):
+
+- `.../cursor/latest` redirects to **`Cursor-2.2.43-...AppImage`**
+- `.../cursor/2.2` redirects to **`Cursor-2.2.44-...AppImage`**
+
+In that situation, **`latest` is behind**. This flake’s updater checks both and will choose **2.2.44**.
+
+This flake’s `update-cursor.sh` default (**auto**) strategy:
+
+- **Checks multiple pointers**: `latest`, the current installed major.minor (e.g. `2.2`), and (if different) `latest`’s own major.minor (e.g. `2.3`).
+- **Picks the highest semver**: so it won’t stick to an old minor, but it also won’t miss patch releases when `latest` lags.
+
 ## Testing

 ```bash