8c745d18e0
Builds out the full v1 scope: a vendored+patched openscreen subset for low-latency Cast Streaming (Mirroring receiver 0F5096E8) alongside the existing Cast V2/HLS and new DLNA/AVTransport casting paths, breadcastd's Idle/Casting state machine with a private IPC socket, the breadcast GTK4 popup as a thin IPC client, and bread.cast.*/bread.command.cast.* breadd integration (device discovery, start/stop, mirroring lifecycle events). Also adds bakery/systemd/Forgejo CI packaging. Validated end-to-end against a real Chromecast/Google TV: negotiated Cast Streaming session, live pipeline playback, and daemon+GUI click-to-cast/ stop through the actual popup.
3.7 KiB
Contributing
breadcast — cast your screen to any Chromecast/Google TV, for Hyprland
(daemon + GTK4 popup).
Part of the bread ecosystem; this repo follows the same branch/release workflow as every other ecosystem product.
Branches
main— release branch, always tag-ready. Nothing is committed to it directly; it only moves forward via abetamerge (see below).dev— integration branch. All day-to-day work lands here first. Every push todevautomatically builds and publishes a dev-track build (see Tracks below) — use this to test your change in a real install before it goes any further.beta— a frozen stabilization branch, cut fromdevperiodically. Every push tobetaautomatically builds and publishes a beta-track build. While a freeze is active, only fixes for issues found in that freeze should land onbeta.
New work — features and bug fixes alike — goes on a short-lived branch:
feature/<short-name>
fix/<issue-number-or-short-name>
Branch off dev, open a PR/push back into dev when ready. If you're fixing
something reported against an active beta freeze, branch off beta
instead, merge the fix there to unblock testers, and also forward the same
fix into dev so it doesn't quietly reappear next cycle.
The release cycle
- Work accumulates on
devviafeature/x/fix/xbranches. Each push auto-publishes a dev build — install it withbakery track set devandbakery update --all, then report or fix anything broken with another push todev. - Once
devhas gone roughly a week without new issues,betais cut fresh fromdev's current tip. This freezes it as the stabilization target —devkeeps moving independently starting the next cycle. betais open for anyone to test:bakery track set betaandbakery update --all. File issues against anything you find on this repo's Forgejo issue tracker. Fixes land viafix/<issue>branches merged intobeta.- Once
betahas gone roughly a month without new issues, it's merged intomainand taggedvX.Y.Z— that tag is what actually triggers the stable release build.betais then reset fromdevto start the next cycle.
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 | main, on a vX.Y.Z tag push |
beta |
Current stabilization freeze | beta, on every push |
dev |
Bleeding edge | dev, on every push |
Dev/beta versions are auto-computed (X.Y.Z-dev.<timestamp>+<sha> /
-beta.…) from the latest published stable tag, so they always sort as
newer than what you have installed — no manual version bumping needed when
pushing to dev or beta.
Local development
cargo build --release --workspace
cargo test --release --workspace
CI
dev-release.yml— triggered on push todev.beta-release.yml— triggered on push tobeta.release.yml— triggered on av*tag push, cuts the actual stable release.
All CI runs on a self-hosted runner; nothing runs automatically on plain commits or PRs beyond the track builds above. See bread-ecosystem's 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.