Publish a release support roadmap

A support policy is a timeline whether you draw it or not. Making it explicit stops the "is this version still supported?" question, and the same format works for any framework, SDK or platform.

A track per version line

Give each major or minor version its own track, ordered newest at the top. Tags keep the lines tidy when a release train has many branches.

Model the phases as ranges

Each support phase is a bounded block of time, so it is a range at day or month precision.

• Active support, range from release to the end of active fixes.
• Security-only support, range for the tail where only security patches land.
• End of life, a point event on the day support ends.
• Long-term support, a range with an extended end date, one track per LTS line.

Deprecations are point events

A deprecation is a moment, not a span. Add it as a point event on each affected line and link the migration guide as a source, so developers land on the upgrade notes from the chart itself.

Keep it current

Roadmaps drift. Because the JSON export is re-importable and the MCP server exposes write tools, you can keep the source in a repo and sync the published timeline from a script or an agent whenever a support date changes.

Embed it in your docs

Publish the timeline and embed it in your documentation or release-notes page. It updates without a redesign, and every line links back to your migration guides.

<iframe src="https://timestrands.com/t/laravel-release-roadmap/embed" style="width:100%;height:520px;border:0" loading="lazy" title="Release support roadmap"></iframe>