> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fased.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Development Channels

# 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`.

<Note>
  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.
</Note>

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:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
fased update --channel stable
fased update --channel beta
fased update --channel dev
```

* `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:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
fased update --channel stable
fased update --channel beta
fased update --channel dev
```

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.