Skip to main content

Prerelease

Publish release candidates without moving the stable latest tag.

Use a prerelease when public testing is useful but the version is not ready for the stable channel.

Choose the version

Use a semantic prerelease identifier such as 0.4.0-rc.1 or 1.0.0-beta.1. State the stability level and upgrade risk in the README and release notes.

Publish to next

The release manifest and publication job must use next. Never publish a prerelease to latest.

bash
npm publish package.tgz --tag next --provenance --ignore-scripts

This command belongs in the trusted publication job, not in a local maintainer procedure.

Update first-party consumers

Pin an exact prerelease in fleet documentation apps and integration fixtures. When the 24-hour quarantine blocks the required first-party version, add one exact temporary exception with a reason and removal time.

Do not promote the same tarball by rebuilding it. When the release becomes stable, certify the stable version through the normal workflow.