Skip to content
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Enhance "LTS every year" section
Added definitions for Alpha and Beta phases, including stability expectations and release frequency details.
  • Loading branch information
aduh95 authored Sep 20, 2025
commit 42258a7a6fe3204cc2bada9b990a97d7ba91b6b2
48 changes: 35 additions & 13 deletions release-schedule-proposal/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,18 +28,37 @@ Here are the release schedule proposals:

## LTS every year

1. alpha duration: 5 months
2. beta duration: 1 months
3. current duration: 6 months
4. active duration: 12 months
5. maintenance duration: 18 months
1. Alpha duration: 5 months
2. Beta duration: 1 months
3. Current duration: 6 months
4. Active duration: 12 months
5. Maintenance duration: 18 months

Total life span (from start of beta until end of maintenance): 37 months

![Release schedule proposal preview](./lts-every-year.svg)

![Release schedule proposal preview](./lts-every-year2030.svg)

### Alpha and Beta definition

#### Stability expectations

Alpha releases may contain semver-major changes (assuming such change does not "break the ecosystem"), but no ABI-breaking changes (so native addons can be tested on those versions).

Once the release has reached the beta period, semver-major changes will no
longer be included, except:

- security fixes
- V8 update
- one-time exception granted by the TSC

Updating V8 during the Beta period is considered the optimal tradeoff, despite
the ABI and API potential breakage, as otherwise the included V8 version would
be 1 year old by the time the release line transitions to LTS.

#### Release frequency

Version | Tentative Date | Type of changes
--------|--------------| -------------
v27.0.0-alpha.0 | 2026-10-20 | Branch-off
Expand All @@ -53,24 +72,27 @@ v27.0.0-alpha.7 | 2027-01-26 | most changes[^1]
v27.0.0-alpha.8 | 2027-02-09 | most changes[^1]
v27.0.0-alpha.9 | 2027-02-23 | most changes[^1]
v27.0.0-alpha.10 | 2027-03-09 | most changes[^1]
v27.0.0-beta.0 | 2027-03-23 | most changes[^1] + V8 update[^2]
v27.0.0-beta.1 | 2027-04-06 | semver-minor only + V8 update[^2]
v27.0.0-beta.0 | 2027-03-23 | most changes[^1] + V8 update
v27.0.0-beta.1 | 2027-04-06 | semver-minor only + V8 update
v27.0.0 | 2027-04-20 | semver-minor only
v27.x.x | 2027-05-04 | …
v27.x.x | 2027-10-05 | …
v27.x.x (LTS transition) | 2027-10-20 |
(Maintenance transition) | 2028-10-20 | _No release_
(End-of-Life) | 2030-10-20 | _No release_
(Maintenance transition) | 2028-10-20 |
(End-of-Life) | 2030-10-20 |

[^1]: Most changes from `main`, except those marked as `dont-land-on-v27.x` because e.g. they contain ABI-breaking changes, or are considered too breaking for the ecosystem, or are moving a deprecation to EOL if 27.x already contains the change moving it to Runtime.

#### Security support

**Security support**: It has not been decided whether security fixes would
TL;DR: TBD

It has not been decided whether security fixes would
trigger a security release, or if those would simply be included in the next
regular release (potentially ahead of schedule). The difference on a maintenance
perspective is that a security release requires locking the CI until all the
queued security releases are ready.

[^1]: Most changes from `main`, except those marked as `dont-land-on-v27.x` because they contain ABI-breaking changes or e.g. are moving a deprecation to EOL if 27.x already contains the change moving it to Runtime.
[^2]: V8 update are (typically) ABI-breaking, however it is considered worth doing given otherwise the V8 version included would be 1 year old by the time the release line transitions to LTS.

## Longer life cycle

1. current duration:
Expand Down