You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My team recently did our first major Node version upgrade and had a bad experience. The short version is: we tried to upgrade to Node 12 (which is in "Current" status as of today, not "Active"). We couldn't get one of our dependencies to build and ended the workday without successfully upgrading.
I'd seen the [releases](https://nodejs.org/en/about/releases/) page multiple times, including during that attempted upgrade. However, that page doesn't explain what the various stages actually mean, and which ones are recommended for production use. Specifically, I didn't understand "Current" vs. "Active", and incorrectly assumed that either would be acceptable for production use, because neither of them was called "unstable", "testing", "alpha", "beta", "prerelease", or other terms that I'm familiar with for a "don't use this in production app yet!" release.
This change adds a paragraph with a brief explanation of the different statuses. I also included a bit about LTS, because I imagine a lot of people seeing this page won't be familiar with that term.
I think that a short explanation on the releases page will save a lot of other teams from this kind of multi-hour upgrade frustration. I've never contributed to this repo, so I may have put this text in the wrong file, and my explanation of the Node release statuses may be wrong in ways I don't understand yet. But I wanted to suggest a concrete change that would've helped us to avoid wasting half of a day.
(My understanding is based on this @jasnell tweet: https://twitter.com/jasnell/status/1128696625986015232.)
Copy file name to clipboardExpand all lines: locale/en/about/releases.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,3 +18,8 @@ schedule-footer: Dates are subject to change.
18
18
---
19
19
20
20
# Releases
21
+
22
+
Major Node.js versions enter _Current_ release status for six months, which gives library authors time to add support for them.
23
+
After six months, odd-numbered releases (9, 11, etc.) become unsupported, and even-numbered releases (10, 12, etc.) move to _Active LTS_ status and are ready for general use.
24
+
_LTS_ release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months.
25
+
Production applications should only use _Active LTS_ or _Maintenance LTS_ releases.
0 commit comments