Support windows vary by project. As published, Node.js LTS typically gets 30 months of critical fixes, Django LTS about three years, Spring Boot majors at least three years with minors at least 12 months, Rails security fixes two years, Go two newest majors, and Angular 12 months active plus 12 long-term. Always confirm on each project's page.
The comparison
| Project | Published policy (as read on 19 October 2026) |
|---|---|
| Node.js | LTS typically guarantees critical bug fixes for a total of 30 months |
| Django | LTS releases get security and data loss fixes, typically three years |
| Spring Boot | Majors at least three years, minors at least 12 months, must run a supported minor |
| Rails | Bug fixes one year, security fixes two years per minor series |
| Go | Each major supported until two newer majors exist |
| Angular | 12 months active, then 12 months long-term with critical and security fixes |
These are summaries of live policies, and policies and dates change. Treat the table as a map, then read the source for your exact version.
Three different models
Time based. Rails, Angular and Spring Boot tie support to months or years from release. You can compute an end date the day you adopt.
Count based. Go supports a fixed number of the newest releases. The end date depends on when the next releases ship, so it moves with the project's cadence. Your plan is to keep within the newest two.
Designated long-term releases. Node.js and Django mark certain releases for extended support. Others get short lives. Node.js has said that, from Node.js 27, every major will move to LTS status after its Current phase on an annual cycle, which changes the old odd and even pattern.
What the differences mean for planning
- The shortest window sets your rhythm. If one of your stacks needs a move every year, put the whole portfolio on an annual upgrade cycle rather than treating each as a one off.
- Minor versus major support is not the same thing. Spring Boot's page ties the three year major window to running a supported minor, and Rails counts its windows per minor series. Reading only the major number can mislead.
- Security only phases are a warning light. After bug fixes stop, you still get security fixes, but the next ordinary bug will stay in your build.
- Count based policies reward small steps. Falling two releases behind means unsupported.
Turn it into a tracker
Create one table in your service catalog with these columns: service, framework, version, end of bug fixes, end of security fixes, next target, owner, and last reviewed. Review it every quarter. Highlight any row with fewer than twelve months left.
For each highlighted row, open a ticket with a date for the upgrade plan, not only the upgrade. Planning takes time too, since you need to find owners, test environments and any blocked dependencies.
When a window closes before you are ready
Choose one of four paths and write it down: upgrade, buy extended support if the project offers it, isolate the system with compensating controls, or retire it. Each carries a cost, and an exception without a review date is a decision to forget about it.
Quick check
Is an LTS release supported forever?
No. Long-term means a longer fixed period, such as the 30 months or three years in these policies.
Where do I find the current dates?
On each project's own release or maintenance page, which is the source for every figure above.
Safeguard inventories the frameworks and runtimes in your services and flags components that have passed end of support. A free scan is available at gold.safeguard.sh/scan.
Sources
- Node.js previous releases
- Django release process
- Spring Boot Supported Versions
- Rails maintenance policy
- Go release policy
- Angular releases
Last reviewed: 19 October 2026.
