Add article: Node.js release schedule and version number changes

.claude/content-calendar.md

@@ -85,6 +85,7 @@
 | Installing Node.js       | UPDATED  | /blog/5-ways-to-install-node-js                          |
 | Docker development       | COMPLETE | /blog/node-js-development-with-docker-and-docker-compose |
 | What's new in Node.js 26 | NEW      | /blog/whats-new-in-nodejs-26                             |
+| Node.js release schedule changes | NEW | /blog/nodejs-release-schedule-changes               |
 
 ---
 
@@ -140,6 +141,15 @@ What's new in Node.js 26 (NEW)
     └── companion repo: github.com/lmammino/nodejs-26-examples (every snippet runnable)
     └── inbound opportunities → Async Iterators, HTTP Requests, Stream Consumer, Checking Node.js version
        (each could mention the relevant v26 update with a link back)
+    └── links to → Node.js release schedule changes (NEW) — "Node.js 26 is the last release of the old model" note
+
+Node.js release schedule changes (NEW)
+    └── links to → Installing Node.js (existing) — old odd/even model reference
+    └── links to → Checking Node.js version (existing) — how to check your version + LTS advice
+    └── links to → What's new in Node.js 26 (existing) — "what ships inside the releases" companion
+    └── inbound update notes ← Checking Node.js version, Installing Node.js, What's new in Node.js 26
+       (each carries a :::note pointing here, since their odd/even explanations are now superseded)
+    └── evergreen hub for "node js release schedule" / "node js lts" / "node js versioning" queries
 
 Security Cluster (future)
     └── Path Traversal Security (hub for file security)
@@ -179,5 +189,13 @@ Security Cluster (future)
 - **Node.js major-release announcements** (the v26 article) make a strong recurring slot:
   evergreen-but-timely SEO around release time ("what's new in Node.js X" queries), and
   they double as a hub linking back to evergreen guides (HTTP, async iterators, streams,
-  install). Plan one per even-numbered LTS major (next: v28 in April 2027). Companion
-  GitHub repo with runnable snippets is a strong differentiator.
+  install). Companion GitHub repo with runnable snippets is a strong differentiator.
+  NOTE: from the 2026 release-schedule change, there is now **one major a year** (every
+  April, LTS in October), so plan one "what's new" article per year, not two. Next: v27
+  in April 2027.
+- **Node.js release-policy / schedule changes** are a second, distinct recurring hook:
+  the release-schedule-change article (June 2026) shows that policy news (not just feature
+  news) ranks well and ages into an evergreen reference. It targets "node js release
+  schedule" / "node js lts" / "node js versioning" and acts as the canonical explainer the
+  evergreen guides (install, checking-version) can point to whenever the model shifts.
+  Revisit whenever the official schedule changes again.

src/content/blog/checking-node-js-version/index.md

@@ -30,13 +30,17 @@ Knowing your versions is crucial for several reasons:
 5. **Project requirements**: Many projects specify minimum version requirements in their documentation
 6. **Support and maintenance**: **This is critical** - according to the [official Node.js releases roadmap](https://nodejs.org/en/about/previous-releases), production applications should only use **Active LTS** or **Maintenance LTS** releases
 
-The Node.js project follows a predictable release cycle where:
+The Node.js project follows a predictable release cycle. Through Node.js 26, that cycle works like this:
 
 - Major versions are "Current" for six months
 - Odd-numbered releases become unsupported after six months
 - Even-numbered releases move to "Active LTS" with critical bug fixes guaranteed for 30 months
 - Older, unsupported versions may have unaddressed security vulnerabilities
 
+:::note[Heads-up: the release model changes from Node.js 27]
+Starting in October 2026, Node.js moves to **one major release a year**, version numbers line up with the calendar year, and **every release becomes LTS** (the odd/even rule goes away). The support windows stay similar, so the advice below, "run a supported version, ideally LTS", does not change. For the full picture, see our guide on [the new Node.js release schedule and version numbers](/blog/nodejs-release-schedule-changes/).
+:::
+
 <figure>
 
 ![Horizontal timeline of the Node.js release schedule from Jun 2025 to Jun 2027. Rows for Main, 20, 22, 24, 25, 26. Colors: orange = unstable, green = current, blue = active, gray = maintenance. Node.js 20 is maintenance until May 2026. Node.js 22 is active to Nov 2025, then maintenance to May 2027. Node.js 24 goes current → active → maintenance (from Nov 2026). Node.js 25 is current Oct 2025–Apr 2026, then brief maintenance. Node.js 26 is current May–Nov 2026, then active.](./nodejs-releases-schedule-2025-09-09.svg)

src/content/blog/installing-node-js/index.md

@@ -58,11 +58,15 @@ Before moving on and exploring all the different installation options, it is def
 
 Node.js offers 2 main release lines:
 
-- **Stable** (or _Current_): every new major Node.js release is considered "Current" for the first 6 months after the publish date. The idea is to give library authors the time to test their compatibility with the new release and do any necessary change. After the 6 months period, all the odd release numbers (9, 11, 13, 15, etc.) move to the state of _Unsupported_, while even releases (10, 12, 14, etc.) are promoted to _Long Term Support_ (or "LTS").
+- **Stable** (or _Current_): every new major Node.js release is considered "Current" for the first 6 months after the publish date. The idea is to give library authors the time to test their compatibility with the new release and do any necessary change. Through Node.js 26, after the 6 months period, all the odd release numbers (9, 11, 13, 15, etc.) move to the state of _Unsupported_, while even releases (10, 12, 14, etc.) are promoted to _Long Term Support_ (or "LTS").
 - **LTS**: releases marked as "Long Term Support" get critical bug fixes for a total of 30 months since the initial publish date. This makes LTS releases particularly suitable for production deployments. The most recent LTS is also called _Active LTS_, while previous LTS versions (still under the 30 months support timeframe) are called _Maintenance LTS_.
 
 Finally, the release coming from the current _master_ branch is considered **Unstable**. This is generally a release dedicated to people maintaining Node.js or developers who want to explore new experimental features that haven't been yet included in any of the major releases.
 
+:::note[The release model changes from Node.js 27]
+The odd/even rule described above applies through Node.js 26. Starting in October 2026, Node.js moves to **one major release a year**, version numbers line up with the calendar year, and **every release becomes LTS**. The practical advice does not change (for production, stick to LTS), but the version numbering does. See our full guide on [the new Node.js release schedule and version numbers](/blog/nodejs-release-schedule-changes/).
+:::
+
 Node.js publishes an [official timeline of current and future releases](https://nodejs.org/en/about/releases/). You can always check the current release schedule on the official Node.js website.
 
 If you are still wondering which release should you use, going with the _Active LTS_ is almost always the best choice, especially if you are building production applications. As of 2026, Node.js 22 is the current Active LTS version.