Release Channels
Why we tag our builds
Clear channel names set expectations for stability, support, and upgrade risk. By offering three well-defined stages—Alpha, Beta, and Release—we let you decide when to adopt new functionality while keeping production systems safe.
1. Alpha Builds
Intended for | Internal teams, early-access partners, power users comfortable with debugging |
Goal | Validate brand-new features or architectural changes as quickly as possible |
State | Feature set still in flux; incomplete documentation; performance un-tuned |
Version tag |
|
Key notes | May be withdrawn without notice. Never run in production. |
2. Beta Releases
Intended for | Broader customer community willing to provide structured feedback |
Goal | Prove that the feature-complete code works on real workloads and environments |
State | Most major bugs fixed; edge-case defects and performance tuning remain |
Version tag |
|
Key notes | Upgrades between Betas can introduce breaking changes. Support is best effort. |
3. Release (Stable / GA)
Intended for | All customers, including mission-critical production deployments |
Goal | Deliver a fully supported, long-term baseline |
State | Thoroughly tested, security-scanned, performance-optimized, fully documented |
Version tag |
|
Key notes | Only backward-compatible fixes land in patch/minor versions until the next major cycle. |
Choosing the right channel
Your use-case | Recommended channel | Why |
|---|---|---|
Prototype a new integration | Beta | Features are final; instability risk acceptable |
Run CI/CD pipeline tests | Beta | Mirrors near-future production build |
Production deployment | Release | Guaranteed stability & formal support |
Influence early design | Alpha | Fastest iteration loop, highest impact |
Version suffix cheat sheet
(alpha)→ Experimental snapshot(beta)→ Feature-complete preview(no suffix) → Stable / GA
Support & feedback matrix
Channel | SLA | Where to report issues |
|---|---|---|
Alpha | None | GitHub issues ( |
Beta | Best-effort | In-app reporter or GitHub ( |
Release | Contractual | Support portal |
Frequently asked questions
Can I skip straight from Alpha to Release?
Yes. Read the Release Notes carefully—breaking changes may have occurred.
How long does each phase last?
Typical cadence: Alpha (1–3 weeks), Beta (4–6 weeks), Release (supported until the next major version). Actual timing can vary per feature set.
Why don’t we keep permanent Betas like some products?
We treat “Beta” as a time-boxed validation window. Lingering Betas blur expectations around support and stability.