Skip to content

release.md

Latest commit

 

History

History
107 lines (79 loc) · 3.39 KB

release.md

File metadata and controls

107 lines (79 loc) · 3.39 KB

Release Prep

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.toml and 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-run for dependent crates will still resolve dependencies from crates.io and fail until the earlier crates are actually published. That failure is expected for:
    • taskers-control
    • taskers-runtime
    • taskers-ghostty
    • taskers-cli
    • taskers

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.xz
  • Publish the GitHub release so the Ghostty runtime asset is publicly downloadable before publishing the crates.
  • 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-cli
cargo publish -p taskers

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 --locked still works as the standalone helper path.
  • Confirm cargo install taskers --locked on 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.