When a team chooses a software or framework version, it may see a newer release beside one labeled LTS. The larger number suggests newer features, while LTS concerns support. Neither label alone identifies the right choice.
LTS means that a particular project promises to maintain a release under its own rules. This matters to anyone choosing a version or deciding whether to keep the current one: a mistaken assumption can leave a project without promised fixes or with incompatible components.
Before choosing, answer four questions: who supports the release, until what date, which problems are covered, and which components are compatible with it. This article shows how to find those answers without installing or upgrading software.
LTS is a bounded promise from a particular project
LTS means long-term support. A product team identifies a release and publishes its maintenance policy, including the support period, included fix categories, and any additional conditions.
There is no single LTS duration shared by all products. One project may provide several years of security fixes. Another may define a different period, set of fixes, or access conditions. The label does not replace the official policy.
For Django, begin with the official downloads and supported-versions page. The release-process documentation helps identify the rules for different branches, while the installation documentation is where environment requirements should be checked. Do not transfer dates or rules from one branch to another; verify them in the current documentation on the date of the decision.
Three misleading conclusions
“LTS is the newest version”
Not necessarily. Regular releases with larger version numbers and newer features may appear after an LTS release. They may also be supported, but their schedule and rules require a separate check.
“LTS is always the safest choice”
The label describes promised maintenance, not the present state of a particular installation. Check the exact patch version, known issues, runtime, third-party packages, configuration, and usage. LTS does not remove the need to apply required fixes.
“A supported version is compatible with everything”
Support and compatibility answer different questions. Support describes which fixes a project promises and for how long. Compatibility describes whether the selected framework, runtime, package, database, and other component versions can work together under stated conditions.
Evidence to collect
Before any upgrade, build a short matrix.
- Current state: framework, runtime, and key dependency versions, plus the file or read-only command that confirms each value.
- Support: support end date and fix categories for the current and considered branches.
- Compatibility: permitted runtime versions and important package constraints from official sources.
- Product need: the required support period and the features that make the team consider another version.
- Evidence: a direct official link, the check date, and clearly marked unknowns.
The matrix is not a migration plan or permission to upgrade. It only shows which options have source evidence and what still needs investigation.
How to involve an AI agent safely
An agent can draft the inventory and consolidate facts from several sources. The learner must first understand the difference between support and compatibility and set the boundaries of the task.
Give the agent a separate local copy with a clean version-control state and an approved list of tracked files. Permit only reading those files, safe local version checks, and inspection of official documentation.
Prohibit reading .env or other secrets, installing or upgrading packages, changing code or lockfiles, running migrations, accessing production, or modifying containers. The agent must stop if a command may write data, a version can be discovered only from production, or official sources conflict.
The expected artifact is a dated matrix containing components, versions, support windows, compatibility facts, direct URLs, and explicit gaps. Independently open every source, compare its dates and wording, and confirm that the project diff is empty. A confident agent recommendation without that verification is not evidence.
How to read a reference to Django 6.1 and 6.2 LTS
If a news report calls one release regular and the next one a planned LTS release, it is describing their proposed roles in the release calendar. It does not prove that the LTS release is already available, that its dates cannot change, or that it fits your project.
Check the current status of both releases on Django’s official page and verify dates and rules in the current release-process documentation. A project decision also requires the actual Python, Django, and dependency versions, compatibility evidence, tests, and a separately approved migration plan.
Bottom line
LTS is a useful support-policy label, not a universal guarantee of novelty, security, or compatibility. Its meaning comes from the particular project’s rules, support period, included fix categories, and compatibility conditions.
First collect and independently verify evidence without changing the project. Then decide whether to remain on the current supported branch or investigate a migration separately.
Official sources:
Make a version decision from evidence
The agent helps collect a read-only inventory and official support dates. It does not install or update packages, runtimes, lockfiles, databases, or production.
Completed steps:0 / 0
I have a project but do not know whether it needs an LTS versionStart with a separate local working copy and dependency declarations. Upgrading is outside this exercise.
Turn the LTS label into four questions
Identify who supports the release, until when, which fixes are included, and under what conditions.
Boundaries, checks, and agent brief
Understand first
- LTS duration and included fixes are not identical across projects.
Safe context for the agent
- This article's section about the promise boundary.
Allowed
- Explain novelty, support, and compatibility without project access.
Not allowed
- Recommend a concrete upgrade without versions, project policy, and compatibility evidence.
Stop when
- You still treat LTS as 'newest' or 'safe forever.'
How to verify
- Apply the questions to another product and check why its own policy is required.
Goal: Identify who supports the release, until when, which fixes are included, and under what conditions. Safe context for the agent: - This article's section about the promise boundary. Allowed: - Explain novelty, support, and compatibility without project access. Not allowed: - Recommend a concrete upgrade without versions, project policy, and compatibility evidence. Stop when: - You still treat LTS as 'newest' or 'safe forever.' Expected artifact: Your four questions for any LTS label. How to verify: - Apply the questions to another product and check why its own policy is required.
Inventory versions without installing
Find declared runtime, framework, and key dependency versions.
Boundaries, checks, and agent brief
Understand first
- A declared version, lockfile, and running environment can differ.
Safe context for the agent
- A separate local copy, clean version-control state, and approved manifest, lockfile, and runtime files.
Allowed
- Read only approved tracked files and run local version commands that do not install or update components.
Not allowed
- Read .env or secrets; run install/update; change lockfiles, code, databases, containers, or production.
Stop when
- There are unexplained local changes, a version is known only from production, or a command may access the network or write files.
How to verify
- Open every source yourself and confirm an empty diff.
Goal: Find declared runtime, framework, and key dependency versions. Safe context for the agent: - A separate local copy, clean version-control state, and approved manifest, lockfile, and runtime files. Allowed: - Read only approved tracked files and run local version commands that do not install or update components. Not allowed: - Read .env or secrets; run install/update; change lockfiles, code, databases, containers, or production. Stop when: - There are unexplained local changes, a version is known only from production, or a command may access the network or write files. Expected artifact: A table with component, declared version, file evidence, and gaps. How to verify: - Open every source yourself and confirm an empty diff.
Plan the support check
Name official pages and compatibility relationships before searching for an answer.
Boundaries, checks, and agent brief
Understand first
- Framework support does not guarantee runtime or third-party package compatibility.
Safe context for the agent
- The inventory and official domains for each major component.
Allowed
- Propose read-only checks of support policy, compatibility pages, and release notes; name dates and claims to capture.
Not allowed
- Move to migration work, change versions, or rely on a random blog instead of project sources.
Stop when
- No official source exists or the installed version is unclear.
How to verify
- Check that every future decision has separate evidence, not only an LTS label.
Goal: Name official pages and compatibility relationships before searching for an answer. Safe context for the agent: - The inventory and official domains for each major component. Allowed: - Propose read-only checks of support policy, compatibility pages, and release notes; name dates and claims to capture. Not allowed: - Move to migration work, change versions, or rely on a random blog instead of project sources. Stop when: - No official source exists or the installed version is unclear. Expected artifact: A matrix plan: component → current version → support → compatibility → source. How to verify: - Check that every future decision has separate evidence, not only an LTS label.
Fill the matrix without upgrading
Collect current official support and compatibility facts.
Boundaries, checks, and agent brief
Understand first
- The check date matters because roadmaps and support windows change.
Safe context for the agent
- The approved plan, inventory, and official pages.
Allowed
- Open official sources; record check date, support end, fix types, stated compatibility, and direct URLs.
Not allowed
- Download packages, edit the project, run migrations, tests, or staging/production deployments.
Stop when
- Sources conflict, information has no date, or a fact would require guessing.
How to verify
- Open each URL and compare every number, date, and fix category with the source.
Goal: Collect current official support and compatibility facts. Safe context for the agent: - The approved plan, inventory, and official pages. Allowed: - Open official sources; record check date, support end, fix types, stated compatibility, and direct URLs. Not allowed: - Download packages, edit the project, run migrations, tests, or staging/production deployments. Stop when: - Sources conflict, information has no date, or a fact would require guessing. Expected artifact: A dated support matrix with URLs and explicit unknowns. How to verify: - Open each URL and compare every number, date, and fix category with the source.
Separate facts from the decision
Check the matrix and describe options without a hidden upgrade.
Boundaries, checks, and agent brief
Understand first
- One supported version may fit a new project while another fits a constrained stable product.
Safe context for the agent
- The matrix, project requirements, and check date.
Allowed
- Mark confirmed facts, unknowns, risks of staying, and risks of migration.
Not allowed
- Declare one version universally correct or perform changes.
Stop when
- The recommendation ignores the runtime, key dependencies, or required support period.
How to verify
- Another person should reproduce the conclusion using only the matrix and sources.
Goal: Check the matrix and describe options without a hidden upgrade. Safe context for the agent: - The matrix, project requirements, and check date. Allowed: - Mark confirmed facts, unknowns, risks of staying, and risks of migration. Not allowed: - Declare one version universally correct or perform changes. Stop when: - The recommendation ignores the runtime, key dependencies, or required support period. Expected artifact: A 'stay / investigate migration' decision with evidence and open questions. How to verify: - Another person should reproduce the conclusion using only the matrix and sources.
Explain the choice without LTS magic
State what is supported, why it is compatible, and what remains unchecked.
Boundaries, checks, and agent brief
Understand first
- A version decision is a dated snapshot, not a permanent guarantee.
Safe context for the agent
- The verified matrix and previous decision.
Allowed
- After your explanation, identify an unsourced claim or missing dependency.
Not allowed
- Write the justification for you or turn it into upgrade approval.
Stop when
- You cite only the LTS label or omit the support end date.
How to verify
- For every sentence, provide a URL or mark it as a decision or unknown.
Goal: State what is supported, why it is compatible, and what remains unchecked. Safe context for the agent: - The verified matrix and previous decision. Allowed: - After your explanation, identify an unsourced claim or missing dependency. Not allowed: - Write the justification for you or turn it into upgrade approval. Stop when: - You cite only the LTS label or omit the support end date. Expected artifact: Your short conclusion with date, support boundary, compatibility, and next read-only check. How to verify: - For every sentence, provide a URL or mark it as a decision or unknown.