Add BreadClient::command (unsourced bread.command.<app>.<verb> emit) plus health/api_version, and a clap-free screenshot_cli helper for the next pin. get.sh now dies if minisign or .minisig is missing — checksum-only is not enough to install. Generate the README products table from the registry, and refresh release-channels/CONTRIBUTING/CLAUDE.md to match.
4.3 KiB
Contributing
This repo is a Cargo workspace. Bakery-channel products shipped from here
are bakery (the ecosystem package manager) and bread-theme (the shared
theming crate). Shared crates that sibling apps pin — not bakery packages
of their own — are bread-utils, bread-onnx, bread-screenshots, and
bread-capture. Other ecosystem products (bread, breadbar, breadbox,
…) live in their own repos under Breadway/ but follow the same workflow
described here. The product list is registry/bread-ecosystem.toml.
Branches
There is one long-lived branch: main. All day-to-day work lands here.
Every push to main automatically builds and publishes a dev-track
build for both products (see Tracks below) — use this to test your change
in a real install before cutting anything more formal.
New work — features and bug fixes alike — goes on a short-lived branch:
feature/<short-name>
fix/<issue-number-or-short-name>
Branch off main, open a PR/push back into main when ready. Short-lived
branches get deleted on merge — they never accumulate the kind of drift a
second long-lived branch does.
The release cycle
There's no separate beta or release branch — "stable" and "beta" are both
just tags on main, not branches that need to be kept in sync:
- Work accumulates on
mainviafeature/x/fix/xbranches. Each push auto-publishes a dev build for bothbakeryandbread-theme— install withbakery track set devandbakery update --all, then fix anything broken with another push. - When you want to stabilize before a real release, tag a release
candidate:
git tag vX.Y.Z-rc.1 && git push origin vX.Y.Z-rc.1(push to both remotes). That tag alone triggers a beta-track build — "freezing" is just pausing pushes tomainwhile you test it, not a branch operation. Cut-rc.2,-rc.3, etc. for further fixes. - Once an RC has gone without issues, tag the real release:
git tag vX.Y.Z && git push origin vX.Y.Z— that's what triggers the signed stable release build.
Note: bakery and bread-theme share the same v* tag pattern
(both release-bakery.yml and release-bread-theme.yml trigger on
tags: ['v*'], pre-existing behavior this doc isn't changing) — a single
tag push builds and publishes a release for both products at once. If
you ever need to release one independently of the other, that's a real gap
worth fixing in the workflow files themselves, not something to work around
by hand.
Tracks, from a user's perspective
bakery track show # what you're currently on (defaults to stable)
bakery track set dev # or beta, or stable
bakery update --all # pull the latest build on your current track
| Track | What it is | Published from |
|---|---|---|
stable |
The last tagged release | a vX.Y.Z tag |
beta |
Latest release candidate | a vX.Y.Z-rc.N tag |
dev |
Bleeding edge | main, on every push |
Dev versions are auto-computed (X.Y.Z-dev.<timestamp>+<sha>) from the
latest published stable tag, so they always sort as newer than what you
have installed — no manual version bumping needed. Beta versions are just
the RC tag itself (already valid semver, already sorts below the real
release it's a candidate for).
Local development
cargo build --release -p bakery
cargo test --release -p bakery
bakery, bread-theme, bread-utils, bread-onnx, bread-screenshots,
and bread-capture are all workspace members. Run the same commands with
-p bread-theme --bin bread-theme for that crate, or -p bread-utils --features bread-client for the IPC client.
CI
dev-bakery.yml/dev-bread-theme.yml— triggered on push tomain.rc-bakery.yml/rc-bread-theme.yml— triggered on anyvX.Y.Z-rc.Ntag push.release-bakery.yml/release-bread-theme.yml— triggered on any otherv*tag push, cuts the actual stable release.package.yml— publishesbakeryto the[breadway]pacman repo, also tag-triggered.
All CI runs on a self-hosted runner; nothing runs automatically on plain
commits or PRs beyond the track builds above. See
docs/release-channels.md for the full policy,
including how a new product gets wired onto these tracks.
Questions
Open an issue on this repo's Forgejo tracker.