### System details

Omarchy: 3.8.3 | Arch Linux | Waybar custom/update module: "exec": "omarchy-update-available"

### What's wrong?


On Omarchy, Waybar shows the **"updates available"** icon when the system is not up to date. This icon is controlled by `bin/omarchy-update-available`, which runs periodically.

The problem is that the icon **never disappears**, even when the system is fully up to date.

### How the script currently works

`bin/omarchy-update-available` compares two versions:

1. **Locally installed version**

   * Obtained from the Git tags in the repository cloned at `~/.local/share/omarchy`.
   * It uses `git describe --tags` on the most recent commit that has a tag.

2. **Latest remote version**

   * Obtained by listing all tags from the GitHub repository using `git ls-remote --tags`.
   * The tags are sorted using `sort -V`, and the last one is considered the latest version.

If the remote version differs from the local version, the script prints `update available` and returns exit code `0`, causing Waybar to display the update icon.

### What's causing the issue?

The Omarchy repository currently contains a prerelease tag:

```text
v4.0.0-beta3
```

When the tags are sorted with `sort -V`, `v4.0.0-beta3` is considered newer than the latest stable release:

```text
v3.8.4
```

Because the script does not filter prerelease tags, it always considers `v4.0.0-beta3` to be the latest version.

This creates an endless loop:

1. The user has `v3.8.4` installed, which is the latest stable release.
2. `omarchy-update-available` reports `v4.0.0-beta3` as an available update.
3. The user clicks the update button and runs `omarchy update`.
4. Git reports `Already up to date`.
5. Pacman reports `there is nothing to do`.
6. The Waybar icon appears again because the script still sees `v4.0.0-beta3` as newer than `v3.8.4`.

In other words, the update checker is reporting an update that the stable channel **cannot and will not install**.

### Why isn't the beta installed?

`omarchy update` pulls from the branch/channel followed by the user's installation.

`v4.0.0-beta3` is a prerelease for the beta/RC development channel, so it is not part of the stable update path.

Therefore, the update checker is comparing the stable installation against a version from a different release channel.

### Expected behavior

Prerelease tags such as:

```text
-beta
-rc
-alpha
```

should not be considered when checking for updates for stable-channel users.

For example, with:

```text
Installed: v3.8.4
Latest stable: v3.8.4
Latest prerelease: v4.0.0-beta3
```

the update checker should report:

```text
up to date
```

and the Waybar update icon should disappear.

The icon should only reappear when a new stable release is published, for example:

```text
v4.0.0
```

### Possible technical fix

The simplest fix would be to filter prerelease tags before running `sort -V`.

For example:

```bash
grep -vE -- '-[A-Za-z]'
```

This would exclude tags containing a hyphen followed by letters, such as:

```text
v4.0.0-beta3
v4.0.0-rc1
v4.0.0-alpha1
```

A potentially better solution would be to determine the release channel/branch the current installation is following and compare against the latest tag belonging to that channel. This would prevent stable users from seeing RC/beta updates altogether.

### Possible secondary issue

There may also be a related issue with the local repository configuration.

In this installation, the Omarchy repository is configured with:

```text
remote.origin.fetch = +refs/tags/v3.8.4:refs/tags/v3.8.4
```

This appears to fetch only the specific `v3.8.4` tag rather than the normal branch history.

If this configuration is not intentional for the stable channel, it could explain why `omarchy-update-git` is unable to advance the local repository when an update is available.

This should probably be investigated separately or confirmed as intentional behavior.

### Additional context

This does not appear to be an isolated installation issue.

The same update-checking logic without prerelease filtering exists in the `master` branch of the repository. Therefore, any stable-channel installation could potentially experience the same issue whenever a prerelease tag becomes newer than the latest stable release.

Issue **#1164** previously reported a similar symptom and was fixed, but that fix does not appear to cover the case where a newer prerelease tag exists.

### Suggested fix

The update checker should compare the installed version against the **latest stable version for the user's current release channel**, rather than simply selecting the highest Git tag.

At minimum, prerelease tags should be excluded from the stable update check.

**Expected result:** Stable users should only see the Waybar update notification when there is an actual update that `omarchy update` can install.