A release cycle that drops old versions on a schedule is a policy. The policy says which versions still get fixes and for how long, and the sentence it writes is the thing that decides whether a user's problem ever gets a fix.
About 1 min of reading
Classify a version.
The window
Before you run it, say out loud what it will print. Then open the answer.
Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.
The window belongs in the documentation a user reads. A policy that lives in a team's heads is a policy that a user cannot plan around, and planning is what an upgrade is for.
How many users are outside the supported window. That number decides whether the policy is generous or the project is quietly abandoning most of its users.
Current gets everything; supported gets fixes for a stated period. Anything outside both gets security fixes only, or nothing. Those three lines are the policy.
A window written as 'two years from its release' moves on its own. Written as a date list, it needs a person to update it, and the update is the thing that gets forgotten.
A fix that matters to an old version has to be applied there on purpose. A fix that only lands in current is a fix that reaches the newest users, who are usually not the ones who reported it.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.