Skip to main content

​
Development channels

Fased ships three update channels for repo-backed updates:
  • stable: latest stable release tag for git checkouts.
  • beta: beta release tag for git checkouts.
  • dev: developer channel for moving head of main.
Fresh machines and hosted VPS installs should start with the curl bootstrap. Source checkout channels use fased update, not package-manager commands. The installer may use the published runtime package internally, but that does not replace Local or VPS Hosting setup.
Maintainers ship builds to beta, test them, then promote a vetted build to stable/latest without changing the version number. Public users should use fased update, not direct package-manager commands.

​
Switching channels

Git checkout:
  • stable/beta check out the latest matching tag (often the same tag).
  • dev switches to main and rebases to the latest upstream commit only. Use fased update --channel dev --safe-fallback only for repair/debug sessions that should try older commits if latest main fails preflight.
git pull --ff-only origin main is a development flow, not a stable release update. The stable end-user path is fased update, which lands on a release tag. Current development fixes become available to stable users only after a new stable tag or package release is published. Update channel commands:
Fresh machines and hosted VPS installs should still use the curl bootstrap first. Package-manager dist-tags are an implementation detail for released runtime payloads, not the public setup decision. When you explicitly switch channels with --channel, Fased also aligns the install method:
  • dev ensures a git checkout (default ~/fased, override with FASED_GIT_DIR), updates it, and installs the global CLI from that checkout.
  • stable/beta resolve to release tags.
Tip: if you want stable + dev in parallel, keep two clones and point your gateway at the stable one.

​
Plugins and channels

When you switch channels with fased update, Fased also syncs plugin sources:
  • dev prefers bundled plugins from the git checkout.
  • stable and beta restore release-channel plugin packages.

​
Tagging best practices

  • Tag releases you want git checkout users to receive through fased update (vX.Y.Z or another stable v* tag for stable, vX.Y.Z-beta.N for beta).
  • vYYYY.M.D.beta.N is also recognized for compatibility, but prefer -beta.N.
  • Legacy vYYYY.M.D-<patch> tags are still recognized as stable (non-beta).
  • Keep tags immutable: never move or reuse a tag.
  • Package-manager dist-tags are maintained for released runtime payloads, but public setup docs should still point users to the Fased installer.

​
macOS app availability

Beta and dev builds may not include a macOS app release. That’s OK:
  • The git tag can still be published.
  • Call out “no macOS build for this beta” in release notes or changelog.