Continues #39778 Closes #40499 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm lint` - [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples) Co-authored-by: Tim Neutkens <tim@timneutkens.nl> Co-authored-by: JJ Kasper <jj@jjsweb.site>
1.1 KiB
Release Channels and Publishing
Next.js has two release channels: stable
and canary
.
Stable
The stable release is what is installed when you npm install next
. This channel is used by the majority of Next.js users.
This channel is published at a regular cadence and follows semantic versioning.
Repository maintainers can publish a new stable version using: pnpm publish-stable
.
The command will ask what version to publish major
, minor
, or patch
.
Canary
The canary channel has to be explicitly installed by users through npm install next@canary
.
This channel is published early based on the canary
branch. It holds all changes that are waiting to be published to the stable channel.
canary
is used to test the latest features and bugfixes on real-world applications.
By installing next@canary
from time to time you can check if your application is affected by any changes that have not been published yet.
Repository maintainers can publish a new canary version using: pnpm publish-canary
.
The command will automatically decide the new version tag as it's an increment from the previous version.