GuideAPP Design · BranchesAndChannels

Branches and Release Channels

Kawaikara keeps source branches, release channels, and documentation previews separate. The active version 3.0 development branch is named dev.

BranchesAndChannels

한국어 · 日本語

Source branches

`main`

main is the stable source line. It contains the currently released 2.x application and the automation used to publish Stable releases. Stable documentation must be generated from an immutable release tag such as v2.3.1, not from an arbitrary working tree.

`dev`

dev is the active development line for version 3.0. New application architecture, Site API changes, Built-in Site Providers, and unreleased fixes are developed here. Staging and Nightly builds select an immutable commit that belongs to dev.

Development work should be described as “the dev branch” or “version 3.0 development.”

Release channels

Channel	Source	Version form	Purpose
Stable	A reviewed release tag, normally from `main`	`3.0.0`	General user releases
Staging	A manually selected commit from `dev`	`3.0.0-staging.N`	Manual pre-release verification
Nightly	An automated immutable commit from `dev`	`3.0.0-nightly.N`	Frequent integration builds

Stable uses the updater channel latest. Staging and Nightly use separate updater channels, application identities, release repositories, and prerelease versions, so they can be installed and updated independently.

Publication versus documentation preview

Showing dev preview or a staging path in the local documentation site does not mean a Staging application build has been published. The local site can render the current dev working tree before any release workflow runs.

A channel is published only after its packaging workflow completes and creates a release in that channel’s release repository. Until then, working-tree documentation is a local preview of the intended channel, not release evidence.

The documentation importer records its source explicitly:

sourceRef: vX.Y.Z means the pages came from an immutable tag.
sourceRef: working-tree means the pages came from the current local dev checkout and must be labeled as a development preview.
A published Staging or Nightly documentation set should use the exact source commit recorded by the release workflow.

Promotion rules

Develop and review version 3.0 changes on dev.
Use Nightly for continuous integration feedback when a Nightly workflow is enabled.
Manually publish Staging from a chosen dev commit when release-level verification is needed.
Promote a reviewed commit to a versioned Stable tag only after compatibility, packaging, update, and migration checks pass.
Regenerate public documentation from the same immutable commit or tag as the published application.

This keeps the branch name, application channel, documentation version, and downloadable artifact traceable without treating a local preview as a release.