docs: document release channels and revive LTS on 2.9 line#3418
Open
bartlomieju wants to merge 1 commit into
Open
docs: document release channels and revive LTS on 2.9 line#3418bartlomieju wants to merge 1 commit into
bartlomieju wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Users get confused about what release "channel" they are on, why the same
version number can behave differently, and what each
deno upgradevariantdoes. This adds a channel mental model to the stability page and reflects that
the LTS channel is back on the Deno 2.9 line, starting with v2.9.3.
The stability page now describes all four channels (stable, lts, rc, canary,
plus alpha/beta during a major prerelease cycle) as independent tracks, explains
that a binary belongs to exactly one channel baked in at build time, and spells
out the idea that the same version number can be two byte-different builds: a
bare version number always resolves to the stable build, while the LTS build of
the same version is selected by channel. A table maps each
deno upgradevariant to the channel and build it lands on. The
deno upgradereference pagegains a matching Channels section with examples, including
deno upgrade ltsand the consequence that running
deno upgrade 2.9.3on LTS silently moves youback to stable.
Both pages also note a real limitation confirmed against the source: there is no
deno upgradeform that pins a specific LTS patch version. A channel name alwaysinstalls that channel's latest build, and a version number only ever infers a
stable, rc, alpha, or beta channel, never lts. So
deno upgrade lts 2.9.3silently ignores the version and installs the latest LTS.
All upgrade behavior above is verified against the Deno source
(
cli/tools/upgrade.rs,cli/lib/shared.rs,cli/lib/version.rs): channelresolution in
RequestedVersion::from_upgrade_flags, the per-channel downloadsources (stable from GitHub releases, everything else from dl.deno.land), and
the LTS update-notice wording.
One thing needs maintainer confirmation before merge: the exact 2.9 LTS
maintenance window and end-of-life date. I did not invent these. The historical
LTS table (v2.1, v2.2, v2.5) is kept as-is, and the new v2.9 row shows TBD for
the start and end dates. Please fill these in, or tell me the dates and I will.