Yes. A framework and the language runtime under it follow separate support schedules, so your app can sit on a supported runtime and an unsupported framework, or the reverse. Track both layers as separate inventory rows, with their own status, end date and owner.
Two clocks, one application
Take a Django application. The Django project publishes its own table of supported series. The table we fetched lists 5.2 as a long-term support release with mainstream support ending 3 December 2025 and extended support ending April 2028, 6.0 with mainstream support ending 4 August 2026 and extended support ending April 2027, and 6.1 with extended support ending December 2027. Older series such as 4.2 do not appear in the table of supported series. The Python interpreter under it has a different table, maintained by a different group, with different dates.
Rails works the same way. Its maintenance page gives separate windows for bug fixes and security issues for each series, and says that once a series is unsupported, fixing bugs and security issues is your own responsibility. Ruby has its own branches page. A Rails app can be on a Ruby that is still in maintenance and a Rails series that is not.
The practical lesson: a runtime status check alone gives false comfort. "We are on a supported Python" does not tell you the web framework is supported.
Why the two layers drift apart
- Different release cadences. Frameworks and languages release on their own calendars.
- Different upgrade costs. Moving a framework major can mean code changes in your app. Moving a runtime minor is often cheaper.
- Different owners. The platform team might own the runtime image while the product team owns the framework.
- Compatibility ranges. Frameworks declare which runtime versions they support. A framework upgrade can force a runtime upgrade, as Laravel's table of supported PHP versions shows.
A layered inventory
Treat each layer as its own row, then add the relationship.
| Layer | Example | Status source |
|---|---|---|
| Operating system or base image | Debian or Ubuntu release | Distribution page |
| Runtime | Python, Ruby, PHP, Java | Language project page |
| Framework | Django, Rails, Laravel, Spring | Framework project page |
| Libraries | Hundreds of packages | Package registry and advisories |
For each application, record the version at every layer, plus the dates. Then the question "what breaks first?" has an answer: sort by the earliest end date across layers.
Which clock sets your deadline
The earliest end date across the layers is your real deadline, not the one you like best. If the framework ends in March and the runtime in December, the framework is the schedule. If the framework supports only a narrow range of runtimes, move them together to avoid doing two rounds of testing.
For example, Laravel 11's end and Laravel 12 and 13 dates are driven partly by the PHP versions each one allows. Django's LTS to LTS planning shows how to pace framework moves.
Quick audit in four steps
- For each application, list the runtime and framework with exact versions.
- Look up each in its own official table and record the end dates.
- Mark the earliest date as the app's deadline.
- Note whether the next step on one layer forces a step on the other.
For the broader view of how those windows compare, see framework support windows compared.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings can be grouped by component, then imagine grouping by layer.
Where Safeguard fits
Safeguard's SBOM and dependency scanning lists framework and library versions from your lock files, and reachability analysis helps show which framework vulnerabilities your code actually reaches. Try the free scan at gold.safeguard.sh/scan.
Quick check
If my runtime is supported, am I fine?
Not necessarily. The framework and libraries have their own schedules.
Which end date should I plan around?
The earliest end date across all layers of that application.
Sources
Last reviewed: 19 October 2026.
