How Unity Releases gets its data, how the views are wired together, and what they mean.
Unity 6 ( 6000.x) is the primary focus. The LTS minor lines (6000.0, 6000.3) get pinned by default; Supported, Beta, and Alpha chips reveal the rest of the Unity 6 stream.
Legacy LTS lines are also indexed for upgrade planning: 2022.3, 2021.3, 2020.3, and 2019.4. They appear on Editor Releases when their chip is ticked, and they can be diffed against each other or against Unity 6 — picking a 2022.3.x → 6000.x diff is fine if you're evaluating the jump. Lane contents on cross-major diffs mix release notes from two independent product lines, so expect noisier output than a within-major diff.
Pre-2019 lines and non-LTS branches of legacy years (e.g. 2022.1) are not indexed.
unity.com/releases/editor/{latest,beta,alpha} and the markdown release-notes file each one links to. We follow the redirect to the actual version page (e.g. whats-new/6000.3.14f1) and parse the release notes into individual line items - version, area, platform tags, impact, risk, issue IDs, package names.unity.com/releases/sitemap/{year}.xml feed the 2019.4 / 2020.3 / 2021.3 / 2022.3 LTS lines. Same parser, same line-item shape as Unity 6, so a cross-major diff returns one homogeneous result set.packages.unity.com/<name> (the npm-style registry endpoint) and ingest its full version history, dist-tags, and Unity-version compatibility ranges. The list of packages is hand-curated in src/lib/ingest/unity-packages.ts because Unity doesn't publish a registry-listing endpoint - npm run check:packages finds new ones in release notes that aren't in the list yet.unity.com/resources - whitepapers, e-books, case studies, and the on-demand video library. Indexed for the Resources page; not classified into release-note lanes.unity.com/blog/rss.source_snapshots with a SHA-256 of the body so re-runs don't double-count.Editor releases and packages are polled on a several-hour cadence; resources and news poll less frequently because the upstream changes far less often. The exact intervals are configured at the deploy layer (Railway crons) rather than in the app, so the authoritative answer is always the live /api/health endpoint - it reports each source's last-success timestamp and hours-since-success, with a stale flag that flips when nothing has succeeded for the better part of a month.
Legacy LTS releases are bundled into the same editor_release ingestion bucket as Unity 6 - one health entry covers both.
src/lib/classification.ts into one impact bucket:The main diff view. Pick two Unity editor versions in the From / To dropdowns and the page lane-buckets every release-note line item shipped between them - blockers, breaking changes, known issues, security & install impact, package updates, API changes, fixes, improvements, features, other changes. Each lane has its own row count, pagination, and (where useful) deduplication behaviour.
Cross-major diffs work too - 2022.3.50f1 → 6000.3.14f1 is a legitimate question and we answer it. Lane contents on cross-major ranges interleave release notes from two product lines, so the row count is high and the noise is real, but the data is correct.
6.3 LTS + 6.0 LTS - tick Supported / Beta / Alpha or the legacy LTS chips (2022.3 / 2021.3 / 2020.3 / 2019.4) to widen the list. Each row links to the per-release detail page; the external-link icon opens the official Unity release page in a new tab.unity.com/resources - whitepapers, e-books, case studies, video sessions. The chip row at the top filters by resource type. Secondary to release intelligence; included because the resources index is otherwise easy to lose track of and some of the documents are useful for upgrade planning.Every release-note that mentions a given Unity issue ID (e.g. /issues/UUM-113215) along with the derived status chip (Open / Fixed / Regressed). When the issue has mentions across multiple Unity majors, a chip row lets you scope the table by major - picking Unity 2022 LTS hides 6000.x mentions and re-derives the status from just the 2022.3 entries. That's how a user on 2022.3 sees “known issue” while a user on Unity 6 sees “fixed” for the same underlying ID.
The Open on Unity Issue Tracker link goes to Unity's own tracker, which is the source of truth - the status chip is just what the locally indexed release notes imply.
unity.com/blog/rss. Secondary to release intelligence and not classified into lanes - mostly here so a search across the site can find a relevant blog post about something the release notes don't fully explain.Issue-status chips are scoped to the major lines visible in the current view. The same underlying issue can correctly read differently across pages:
from → to range. A 2019.4.40f1 → 2022.3.50f1 diff won't tag an issue as fixed in 6000.3.0b1, because the user can't reach the Unity 6 fix without a separate major upgrade.minorLine=2022.3 and a 6000.x fix likewise gets dropped from the derivation./releases/[version]), the status is global. You're looking at one specific release; the chip just tells you whether Unity has shipped a fix anywhere in the indexed history.The behaviour is intentional - a 6000.3 fix that won't backport to 2019/2020/2021/2022 LTS isn't a fix for a user on legacy LTS, and it would be misleading to display it as one.
unity field). On a cross-major diff like 2022.3 → 6000.3 that means each boundary picks the latest package version its editor side actually supports - which is occasionally a lower-numbered version on one side than the other because Unity maintains separate package branches per LTS line (cinemachine 2.x for 2022, 3.x for Unity 6, both still getting maintenance patches). It looks like a downgrade in version numbers but represents a forward move along distinct package families./compare) or in this exact release (/releases/[version]). Carry-forward issues - known problems that existed before this window - get hidden. The boundary comes from the earliest release_date in scope; the SQL asks “does this issue ID appear in any older release?” and drops it if so.manifest.json or just a comma-separated list). Toggling “Affects my team” intersects every visible row's package_names with your list, so HDRP notes vanish if you don't use HDRP. The list lives in a per-browser cookie, never sent anywhere except in the SQL WHERE clause.Persona presets (Director / Balanced / Indie) are three preconfigured filter combos. Picking one stamps a sensible starting filter set; you can then adjust freely from there. Tracked in a per-view cookie so it sticks across sessions.
Saved presets are user-named filter combos - think “Switch cert prep” or “URP only”. Save the current filter state under a name; clicking the chip re-applies it later. Capped at 10 per view, stored in a per-browser cookie. Nothing leaves your machine.
?stream=… so you can paste the filtered view to a teammate.Hand the LLM a URL of the form https://unityreleases.com/compare.md?from=<from>&to=<to> - for example /compare.md?from=6000.0.50f1&to=6000.0.74f1. The endpoint returns the full upgrade diff as text/markdown, bucketed into the same lanes you see on screen, with issue-tracker links and status suffixes on every issue ID. Every per-release bullet carries the release date inline - - **6000.0.74f1** (2026-04-29) Fixed editor crash on launch - so the LLM has chronology without a second lookup. Any tool that can fetch a URL - Claude's WebFetch, ChatGPT browsing, curl, an MCP server - can ingest it directly. No auth, no rate-limit games.
Optional: append &stream=beta (repeatable) to widen the in-between releases beyond LTS. Cross-major diffs (2022.3.x → 6000.x) are supported. See /llms.txt for the full LLM-facing manifest of this site.
/compare.md endpoint serves - a complete, lane-bucketed diff between the two versions, not just the rows currently visible on the page. Filenames follow the pattern unity-<from>-to-<to>-upgrade.mdso they sort sensibly when you keep a folder of them.