Release Channels

NanoPing is distributed through three release channels: Experimental, Beta, and Stable. Each channel represents a different balance between early access to new capabilities and the strength of the stability guarantees we provide. Features move through the channels in sequence, giving us room to develop and refine them before we commit to long-term support.

Choosing the right channel lets you decide how much stability you need and how early you want access to new functionality.

Overview

Every change lands in Experimental first, is promoted to Beta once it has settled, and finally graduates to Stable:

Experimental  ──►  Beta  ──►  Stable

Channel	Purpose	Stability	Recommended for
Experimental	Early access, in-progress work	No guarantees	Testing, previews, early feedback
Beta	Release candidate for Stable	Feature-frozen, may regress	Pre-production validation
Stable	Production-ready releases	Backward-compatibility policy	Production deployments

Experimental

The Experimental channel is built from the latest state of our development branch. It is the first place new features, fixes, and architectural changes appear, and it is intended for users who want to preview upcoming work or provide early feedback.

• Access: Includes in-progress features that have not yet been promoted. Some may be gated behind explicit opt-in flags and are only available on this channel. There is no standard way a feature flag is implemented or toggled; the mechanism varies from feature to feature.
• No guarantees: Experimental features may change, break, or be removed at any time without notice, and a given build may contain regressions.
• Not for production: Use Experimental for evaluation and testing, not for workloads that require stability.

Beta

The Beta channel is the release candidate for the next Stable version. The current state of Experimental is promoted to Beta, where it is feature-frozen and stabilized ahead of a Stable release.

• Purpose: Beta exists to surface regressions before they reach Stable. It gives you a preview of the next Stable release in a near-final state.
• Feature set: No new features are introduced during a Beta cycle. Only bug fixes and stabilization work are applied.
• Limited guarantees: Beta is more stable than Experimental but does not yet carry the full backward-compatibility guarantees of Stable. We recommend it for pre-production validation rather than production use.

Stable

The Stable channel is the recommended channel for production deployments. A new Stable release is cut from Beta after the release candidate has completed its stabilization cycle.

• Production-ready: Stable releases have progressed through both Experimental and Beta before publication.
• Compatibility: Stable releases are covered by our Backward Compatibility Policy, which defines the guarantees that apply across version updates.
• Per major release: Backward compatibility is scoped to a single major release. Upgrading between Stable versions that share the same major version (for example, 10.4.0 to 10.5.0) will not introduce breaking changes. Breaking changes to the Non-Guaranteed Stable Area are reserved for new major releases (for example, 10.x to 11.0.0) and are documented in the release notes. The Guaranteed Stable Area is the exception and remains compatible across major releases.
• Recommended default: Unless you specifically need early access to upcoming features, Stable is the channel you should run.

How Features Progress

Features follow a consistent path from Experimental to Stable. This staged approach lets us develop rapidly without exposing unfinished work to production users.

• Introduction: New features land on Experimental, where they may be gated behind an opt-in flag while they are being developed.
• Promotion to Beta: When a release is prepared, the current Experimental state is promoted to Beta and feature-frozen. A feature is only promoted once it is considered ready for wider testing.
• Graduation to Stable: After a full Beta cycle without blocking issues, the Beta release is published as the next Stable version. At this point the feature is enabled by default and, where applicable, falls under our backward-compatibility guarantees.
• Removal: A feature that does not meet our quality bar can be revised or removed while it is still on Experimental or Beta, without affecting Stable.

Choosing a Channel

• Run Stable for production and any workload where predictability matters. This is the right choice for most users.
• Run Beta if you want to validate your setup against the next Stable release and help catch regressions before they ship.
• Run Experimental if you want to try upcoming features early or give us feedback while work is still in progress, and you can tolerate breaking changes.