description: Use when releasing, version-bumping, or propagating changes across taffybar GitHub org packages (taffybar, gtk-sni-tray, gtk-strut, status-notifier-item, dbus-menu, dbus-hslogger)
---
# Taffybar Ecosystem Release
Release and propagate changes across the taffybar Haskell package ecosystem.
**Manual doc upload required for GTK-dependent packages:** Hackage cannot build documentation for packages that depend on GTK/GI libraries (the build servers lack the system dependencies). This affects `taffybar`, `gtk-sni-tray`, `gtk-strut`, and `dbus-menu`. For these packages you must build haddocks locally and upload them yourself — see the `hackage-release` skill for the `cabal haddock --haddock-for-hackage` and `cabal upload --documentation` commands. Only `status-notifier-item` and `dbus-hslogger` (pure DBus/Haskell deps) can have their docs built by Hackage automatically.
For each package higher in the graph that depends on what you just released, update the dependency bound in its `.cabal` file. For example, if you bumped `gtk-strut` to 0.1.5.0:
Each package's `flake.nix` references its ecosystem dependencies as inputs (typically `flake = false` pointing at GitHub). After pushing changes, update the flake.lock in any repo that directly references the changed package:
The personal NixOS config consumes these packages through a chain of flakes. When doing a system rebuild (`just switch` in `~/dotfiles/nixos`), be aware that there are multiple flake.lock files that may need updating depending on what changed.
All three flakes declare their own top-level inputs for the ecosystem packages and use `follows` to keep versions consistent. The key thing to understand: `path:` inputs snapshot the target flake **including its flake.lock** at lock time. So if you update only the top-level nixos flake.lock, the middle and bottom layers will still use whatever was previously locked in *their* flake.lock files.
This means when propagating a change to a system rebuild, you generally need to update flake.lock files **bottom-up** — the bottom layer first so the middle layer picks up fresh locks, then the middle so the top picks up fresh locks:
Not every change requires touching all three layers. If you only changed taffybar itself, the bottom layer doesn't need updating since it *is* the bottom. If the nixos flake already uses `follows` to override an input from GitHub directly, updating just that top-level input may be sufficient. Think about which flake.lock files actually contain stale references and update those.
