Releases
Latest
We release a latest version every Monday at 1pm US Eastern time using the latest commit to main
at that time. This release is performed automatically by a Github action located in a private repository. This release goes to the standard latest
tag on npm.
See Versioning for how the version number is calculated.
If there have been no commits that impact public-facing packages then a patch-level release shall be released.
Latest releases shall only ever be "minor" or "patch" releases.
Release Notes
Every release is documented on the Github Release page.
These release notes will list the PRs included in the release.
Canary
We release a canary version for each commit to main
that passes all required checks. This release is performed automatically by the publish_canary_version
step. So you never need to wait for a new stable version to make use of any updates.
This release is goes to the canary
tag on npm and it is versioned as an incremental canary patch release on top of the current latest
version. I.e. if the current version is 5.6.1
, then the first canary version will be 5.6.2-alpha.0
, the second 5.6.2-alpha.1
, and so on.
The only exception to the automated publishes described above is when we are in the final phases of creating the next major version of the libraries - e.g. going from 1.x.x
to 2.x.x
.
During these periods, we manually publish canary
releases until we are happy with the release and promote it to latest
.
Installing Canary Versions
To try out the latest canary versions of typescript-eslint, install @typescript-eslint/eslint-plugin@canary
and @typescript-eslint/parser@canary
.
Note that npm may need a --force
to override version requirements.
- npm
- Yarn
- pnpm
npm i @typescript-eslint/eslint-plugin@canary @typescript-eslint/parser@canary --save-dev --force
yarn add @typescript-eslint/eslint-plugin@canary @typescript-eslint/parser@canary --dev --force
pnpm add @typescript-eslint/eslint-plugin@canary @typescript-eslint/parser@canary --save-dev --force
Major Releases
We currently do not have a set schedule around when major releases shall be performed; instead they are done as the need arises.
We keep a backlog of breaking issues as a milestone on GitHub that is named in the form ${major}.0.0
.
When we do do a major release, we release a release candidate version to the rc-v${major}
tag on npm for each commit to the major branch.
See Maintenance > Releases for steps to perform a major release.
Out-of-Band Releases
We will do releases "out-of-band" (outside the latest schedule) for rare emergencies. We assess need on a case-by-case basis though generally an emergency is defined as a critical regression specifically introduced in the latest release.
These releases are done manually by a maintainer with the required access privileges.
Back-Porting Releases
We do not back port releases to previously released major/minor versions. We only ever release forward.