Debian future release strategy proposal

[MikeMcC399]

• Follows on from Update default_variant to trixie #2365
• Relates to Add OS maintenance strategy to documentation #2397

Current situation

According to the settings in versions.json every Node.js release line is set to use Debian 12 (bookworm/oldstable) as default, and images are built for each of the Debian major versions: 11 (bullseye/oldoldstable), 12 (bookworm/oldstable) & 13 (trixie/stable) (see Debian Releases).

Node.js	11 (bullseye)	12 (bookworm)	13 (trixie)
20	used	default	used
22	used	default	used
24	used	default	used
25	used	default	used

Suggestion

Make no change for existing release lines Node.js 20, 22, 24 & 25.

For future release lines starting with Node.js 26:

On release of a new Node.js release line:

• package with only the current Debian stable release (at the moment this is Debian 13.3 (trixie)), not with earlier Debian major versions
• set the default Debian version also to the stable release

During the supported lifetime of a Node.js release line:

• retain the original Debian major version, add any new major Debian version
• retain the original default Debian version for the full lifetime of the Node.js release line

There is no announced date for the release of Debian 14 (forky), however in the past, major Debian Releases have been mid-calendar year every 2 years, so mid 2027 would be a working hypothesis for a possible release date. By this time according to Node.js release details, only Node.js 24 & 26 would still be supported and relevant.

Node.js	11 (bullseye)	12 (bookworm)	13 (trixie)	14 (forky)
20	used	default	used	N/A EOL
22	used	default	used	N/A EOL
24	used	default	used	add when released (TBA)
25	used	default	used	N/A EOL
26	-	-	default	add when released (TBA)

Rationale

• According to principles embedded in Node.js release line strategies, support for environments is maintained for the full lifetime of the release line
• Avoiding packaging of older Debian major versions together with new Node.js release lines reduces the complexity of building, supporting and using Node.js Docker images. This focusses on matching current technology levels together. It also avoids running into the situation where the Debian version is no longer supported where the Node.js release line is still supported. For instance: building Debian 11 (bullseye) with Node.js 24 means that Debian End of LTS on 2026-08-31 occurs before EOL of Node.js 24 on 2028-04-30.

[tianon]

An added data point: when a Debian release transitions from the Release + Security teams over to the LTS team, the list of supported architectures drops (so any existing / supported images will need to drop their supported architectures accordingly).

[MikeMcC399]

@tianon

Thanks for adding the dimension of supported architectures!

Debian announces its new stable release on a regular basis. The Debian release life cycle encompasses five years: the first three years of full support followed by two years of Long Term Support (LTS).

Since Debian in practice releases a new stable release only every 2 years. even if only the stable release is used, it is inevitable that some release lines will be using a Debian version when it meets its end of full support milestone after 3 years and transitions into LTS support with reduced architecture support. So this needs to be described as well.