FAQ

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.

• Editor releases (Unity 6): the three landing pages at 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.
• Legacy LTS editor releases: per-year sitemaps under 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: for each tracked official package, we hit 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.
• Resources: 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.
• News: the official Unity blog RSS feed at unity.com/blog/rss.
• Staff discussions: the Discourse JSON API at discussions.unity.com - we track posts from accounts in Unity's staff user group, keeping each post's edit history so you can see when a Unity answer changed. Surfaced on the Staff Discussions page.
• GitHub: the public REST API for the Unity-Technologies org - every public repo's metadata (stars, topics, language) plus the recent activity feed (releases, pushes, new repos). Surfaced on the Unity GitHub page.

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.

• Active known blockers - known issues with risk level blocker, i.e. things Unity itself flagged as shipping-stoppers.
• Other known issues - known issues that aren't blockers (caution / review level).
• Breaking changes - anything Unity calls a breaking change or that the parser detects as one (deny-listed terms in the body).
• API changes - public scripting API surface changed (signature, rename, removal, new namespace).
• Security & install impact - security fixes and install/platform risks combined.
• Package updates - note pertains to a Unity package version bump.
• Features / Improvements / Fixes / Other changes - straightforward.

• Blocker - Unity-flagged as a shipping-stopper, or the parser detected blocker keywords (crash, data loss, certification-blocking).
• Caution - meaningful regression, some platforms broken, install-time issue.
• Review - needs a human eyeball: API surface changed, package versioning shifted, build pipeline twitched.
• Info - the rest.

A 0–100 composite per Unity release that summarizes six normalized sub-metrics into one number. Higher is better; 100 is the best position, 0 the worst. It appears on Editor Releases (sortable column), each release detail page (header badge), and on Release Visualizer (best/worst leaderboard).

The six sub-metrics roll up into three groups: upgrade risk (50% — breaking surface, blocker rate, mobile issue rate), net cleanup (30% — fix density and the fixes/known-issues delta vs the prior patch), and live debt (20% — known-issue rate users live with after upgrading). Click How this number is computed on any badge for the full per-metric table.

Each release is scored against the population of releases in the same stream — LTS releases are percentile-ranked against other LTS releases, Beta against Beta, Alpha against Alpha. The cohort name and size show up under the badge (e.g. cohort: LTS (72)) so the comparison is visible.

If a stream has too few peers (fewer than 8 releases) the score falls back to the global ALL cohort. This matters mostly for fresh streams; once a stream accumulates eight patches it scores against itself. The cohort baseline is recomputed per request from current data — no frozen snapshots yet, so an old release's score can shift slightly as new releases land.

For each sub-metric: compute the raw ratio per release (e.g. breaking + api_change / total_notes), winsorize at the cohort's 95th percentile (so a mega-release doesn't crush everyone else's scores), apply log1p to compress remaining skew, then convert to a percentile rank within the cohort. For metrics where higher raw is worse (breaking, blockers, known-issues), the percentile is flipped to 100 − percentile. Sub-scores combine into the composite via weighted arithmetic mean.

There's no blocker cap or other categorical override — Unity's blocker labelling is inconsistent enough that a hard cap would drift with their tagging discipline rather than actual release quality. The blocker rate already costs 15% of the composite directly.

The score is confidence-weighted toward the cohort median for releases with sparse data. A release with fewer than 20 parsed notes gets blended proportionally: a 10-note release is 50% raw + 50% median. Below 5 parsed notes the score isn't shown at all (it would just be noise).

The pill goes away once the release has enough data. Users don't see a fake-precision “87/100” off three notes; they see “— / 100, insufficient data” instead, or a provisional badge with the confidence ratio in the hover.

The diff-window equivalent of the Build score. Where Build score answers “how does this single release compare to its peers?”, Upgrade score answers “how does the aggregate of every patch between from and to compare to single-release peers?”

There is no organic cohort of past diffs to score against — two arbitrary diffs span different lengths, streams, and calendar windows. So the Upgrade score treats the diff as a virtual aggregate release: sum the counts across every release in the window, compute the same per-note rates, and score against the global single-release population. The expander on the card explains this caveat inline; the trajectory chart below the score recovers what the aggregate hides.

The net-fix-delta sub-score has a special reinterpretation on diffs: bookend delta (to.netFix − from.netFix normalized by total notes), so the score reflects how the destination patch's net-fix position compares to the starting patch's.

An aggregate Upgrade score number compresses 30 patches into one — useful at a glance, but it hides whether the branch was steadily improving, steadily degrading, or had a V-shape with a rough middle. The trajectory sparkline plots each individual patch's build score in chronological order so the shape of the upgrade is visible: a rising line = each patch scored better than the previous; a falling line = the branch destabilized across this upgrade.

The lowest-scoring patches list calls out the bottom 3 individual scores in the window, each labelled with the group that dragged it down (upgrade risk, net cleanup, or live debt). It answers “where specifically should my QA budget go?” — if a particular patch in the middle is what dragged the aggregate down, it's the one to canary-test.

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.

A visual read on the corpus rather than a row-by-row list. Seven charts stacked vertically, each one answering a different question:

• Stability heat strip — one cell per Unity 6+ release, colored by net-fix score (fixes − known_issues) with a mobile-blocker dot. Reads like a stock chart.
• Best & worst Build scores — top-5 and bottom-5 releases by composite score.
• Known-issues per release, by branch — one line per minor_line; lets you see whether a branch is converging.
• Breaking-change heatmap by domain — rows are curated subsystems (Rendering, Scripting, Mobile, XR, …), columns are recent versions. Cells link into the lane-filtered release page.
• Issue lifespan — introduced → fixed — horizontal bars for the 30 longest-living UUM issues.
• Package drift between editor releases — chronological log showing only the curated packages whose version changed between consecutive editor releases. Empty entries indicate “no curated package changes from prior editor.”
• Patch cadence — dot plot per release stream over the last 18 months.

The domain filter chips at the top pin every chart to one subsystem; the Top-10 facts panel on the side surfaces dynamic SQL-driven highlights (longest-open blocker, fastest fix turnaround, biggest breaking patch, etc.). The trust rail at the bottom names every formula and the last ingestion timestamps.

The landing page for everything UUM-id-shaped. Five sections, top to bottom:

• Stat cards — total tracked issues, currently open, fixed in the last 30 days, regressed (Unity shipped a fix and re-listed). Each card prints its own formula in muted text.
• Newest issues — top 10 by first Known-Issues mention date. What Unity has flagged most recently, regardless of whether a fix has shipped yet.
• Longest-open issues — top 10 by days- since-first-known-mention with no Fix mention (or whose latest Known is newer than the latest Fix). Sorted to surface the bugs Unity hasn't closed out.
• Issues by domain × status heatmap — 13 curated subsystems × {open, fixed}, intensity = count. Answers “where do unresolved issues cluster?” in one glance.
• Most-mentioned issues — top 10 by distinct-release mention count. Surfaces UUM ids Unity kept re-listing across patches (regression treadmills and long-running known issues).

Every issue id and version pill is hover-rich and links into the per-issue detail page (/issues/[issueId]) for the full mention history.

Sortable table of every tracked official Unity package (Input System, Addressables, URP, HDRP, Cinemachine, Burst, and the rest of the curated allowlist). Each row opens a dialog listing every indexed version with its publish date and changelog.

For each version the dialog shows the exact Unity Editor build it first shipped with (e.g. ProBuilder 6.0.4 → 6000.0.23f1), reconciled from the editor release notes rather than the registry's coarse minimum-Unity field. A version that has only reached a preview so far is tagged BETA so a not-yet-stable build isn't read as a shipping version.

Package versions come from packages.unity.com (the npm-style registry). That endpoint is a reliable source of truth only for packages published before Unity 6. Starting with Unity 6 (GA October 2024), Unity moved many packages into the Editor as version-bound core packages and stopped publishing them to the registry - so the registry serves a frozen “latest”. The render-pipeline family is the clearest case: the registry still shows 10.10.1 from October 2022, while Unity 6 actually ships URP/HDRP as 17.x bundled with the Editor.

We don't hide these - the history is real, just frozen - but we flag them so the stale number isn't mistaken for the current one. A package whose newest registry release predates Unity 6 gets a Frozen badge. For Editor-bound packages we go further: every Editor's release notes carry a “Package changes” block pinning the exact bundled version, so we reconcile the real Unity 6 version from there and upgrade the badge to Bundled with Editor with a dated line - e.g. bundled 17.0.3 as of 6000.0.23f1 - last registry release 10.10.1, Oct 2022. Both numbers stay visible so it's clear which is which.

Bottom line: for a pre-Unity-6 package the registry version is current; for an Editor-bound one, trust the bundled version and the Unity 6 / Editor docs, not the registry.

Starting with Unity 6.4, a few core packages adopted unified versioning - the package version is renumbered to match the Editor. com.unity.entities ships as 6.4.0 in Unity 6.4 (its changelog continues straight from the old 1.4.x line). Today this applies to Entities, Entities Graphics, and Collections.

The catch: that 6.4.0 build exists only in the Unity docs. The package registry keeps publishing the old line (1.4.x) as maintenance for Unity 6.0–6.3, so both numbers are real - they just apply to different Unity versions. The Packages note spells it out: Unity 6.4: 6.4.0 · Unity 6.0–6.3: 1.4.7 (registry). The version list in the dialog is the registry's line, so 6.4.0 won't appear there - it isn't published to the registry.

We detect this automatically by probing the Unity docs for each package at the recent Unity 6 minors, and only flag it when the docs version is genuinely newer than the registry latest (so a package that already versions per-Unity, like AR Foundation, isn't mislabeled).

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.

Which repos Unity is actively working on in the open, mirrored from github.com/Unity-Technologies. It defaults to recently updated, and each card shows that repo's latest commit message plus a Released vX flag when there's a recent release - so you can see what just changed and jump in.

Re-sort by stars, newest, or most forks; filter by language or search; and tick Notable only for a hand-curated highlight set (ml-agents, UnityCsReference, Graphics, and the like). Archived repos and forks are hidden by default. The latest commit and release come from the org's public activity, refreshed on the same twice-daily cron as everything else.

Posts written by Unity staff on discussions.unity.com - the official Discourse forum. Only accounts in Unity's unity_staff group are tracked, so it's a low-noise view of what Unity employees are actually saying, without the surrounding community threads.

By default the page shows staff-started topics (the first post of a thread) - product announcements, beta programmes, and release posts. Tick Include replies to also surface staff replies left inside other people's threads. You can further filter by search, category, and author, and sort by recent activity, newest, most replies, or recently edited.

Each post's edit history is kept, so a post that staff later changed is flagged Edited. Titles link straight to the thread on Unity's forum.

Issue-status chips are scoped to the major lines visible in the current view. The same underlying issue can correctly read differently across pages:

• On Upgrade Intelligence, the status reflects only the majors covered by your 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.
• On Search Notes, the status reflects whichever majors are present in the current result set. Filter to minorLine=2022.3 and a 6000.x fix likewise gets dropped from the derivation.
• On /issues/[issueId], the default is “All majors” (the global status). Pick a major chip to re-scope.
• On a single-release page (/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.

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.

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.