Release Prep
April 14, 2026 ยท View on GitHub
This guide is for release maintainers. For everyday usage and operator flows, start with the root README, daily usage, and notifications guide.
Use this checklist before publishing a new taskers Linux release.
1. Finalize The Repo State
- Make sure the release work is recorded clearly in
jj. - Describe the current change with
jj desc -m "<type>: <summary>"if needed. - Split unrelated work into separate changes before publishing.
- Bump the workspace version in
Cargo.tomland update any internal dependency version pins that still reference the previous release.
2. Run Local Verification
- On Ubuntu 24.04, install the Linux UI dependencies first:
sudo apt-get install -y libgtk-4-dev libadwaita-1-dev libjavascriptcoregtk-6.0-dev libwebkitgtk-6.0-dev xvfb
- Run the full active workspace test suite:
cargo test
- Build the mainline app and run the headless smoke:
cargo build -p taskers --bin taskers --bin taskers-gtk
TASKERS_TERMINAL_BACKEND=mock \
bash scripts/headless-smoke.sh \
./target/debug/taskers \
--smoke-script baseline \
--diagnostic-log stderr \
--quit-after-ms 5000
- Verify the installed Linux package layout:
bash scripts/smoke_linux_release_launcher.sh
- Dry-run the leaf crates that do not depend on unpublished workspace siblings:
cargo publish --dry-run -p taskers-domain
cargo publish --dry-run -p taskers-paths
- After you bump the workspace to a new unpublished version,
cargo publish --dry-runfor dependent crates will still resolve dependencies from crates.io and fail until the earlier crates are actually published. That failure is expected for:taskers-controltaskers-runtimetaskers-ghosttytaskers-clitaskers
Before publishing, also verify the operator path still works:
cargo run -p taskers-cli -- --help
cargo run -p taskers-cli -- notify --help
3. Publish
- Push the release tag so GitHub Actions can assemble the assets and attach them to a draft GitHub release.
- Confirm the draft release tagged
v<version>contains:taskers-ghostty-runtime-v<version>-x86_64-unknown-linux-gnu.tar.xztaskers-linux-bundle-v<version>-x86_64-unknown-linux-gnu.tar.xztaskers-linux-bundle-x86_64-unknown-linux-gnu.tar.xztaskers-manifest-v<version>.jsontaskers-manifest.json
- Publish the GitHub release so the runtime, Linux bundle, and manifest assets are publicly downloadable before publishing the crates.
- After the GitHub release is published, the
Sync AUR taskers-binworkflow will automatically render and push thetaskers-binAUR package if theAUR_TASKERS_BIN_SSH_PRIVATE_KEYsecret is configured. - If the AUR sync fails or you need a
pkgrelbump without cutting a new Taskers release, rerunSync AUR taskers-binwithworkflow_dispatchand the target version / pkgrel. - Publish the crates to crates.io in dependency order:
cargo publish -p taskers-domain
cargo publish -p taskers-paths
cargo publish -p taskers-control
cargo publish -p taskers-runtime
cargo publish -p taskers-ghostty
cargo publish -p taskers-core
cargo publish -p taskers-shell-core
cargo publish -p taskers-cli
cargo publish -p taskers-host
cargo publish -p taskers-shell
cargo publish -p taskers
- If you still maintain
taskers-git, push any needed VCS-package updates to its separate AUR repo after the stable release flow finishes.
4. Post-Publish Check
- Verify the Linux install:
sudo apt-get install -y libgtk-4-dev libadwaita-1-dev libjavascriptcoregtk-6.0-dev libwebkitgtk-6.0-dev
cargo install taskers --locked
taskers
- Confirm the published Linux install builds the real app binaries directly and only bootstraps the exact version-matched Ghostty runtime on first launch.
- Confirm
cargo install taskers-cli --bin taskersctl --lockedstill works as the standalone helper path. - Confirm
cargo install taskers --lockedon macOS fails with the Linux-only guidance from the published app package.
For dev-desktop testing against the local checkout after a release pass:
cargo install --path crates/taskers-app --force
That reinstalls the repo-local app into Cargo's bin directory as the real taskers package.