Every starred repository ships versions. Almost none of them deserve a notification.
Starcat's release subscriptions exist for the thin slice you actually depend on: the database driver, the UI kit, the security-sensitive library you cannot afford to ignore.
Subscription is a filter, not a feed
GitHub already has a firehose. Adding another firehose inside Starcat would be a failure.
The useful model is selective:
- Subscribe when a repo is in production, or on a short list of "watch closely"
- Skim assets and notes when something ships
- Mark updates read so the badge means something again
If everything is unread, nothing is urgent.
Pair releases with status
Releases get sharper when the library has status:
- Using → candidates for subscription
- Reading → maybe later
- Archived → almost never
That pairing keeps the release surface proportional to real dependency, not to how enthusiastically you clicked Star in 2023.
A small habit that works
Once a week, open subscribed releases, clear what you have assessed, and unfollow one repo that no longer earns the ping.
Attention is the scarce resource. Release tracking should spend it carefully.