Developer Changelog / Documentation Policy

Old Polaris references will be
limited to the latest 4 versions only

Polaris reference documentation is being unified under the same versioning policy as Shopify's GraphQL API. Each stable version is supported for at least 12 months, and starting with the 2026-04 release, only the four most recent stable versions will be published on Shopify.dev. Older extension versions will continue to work, but their dedicated documentation will be removed.

On this page
  1. What's actually changing (in 30 seconds)
  2. How it works: versions and documentation coverage
  3. The 4 UI extension docs affected
  4. Old vs. new policy comparison
  5. Who's affected and who isn't
  6. Action items for engineers (3 steps)
  7. 5 key technical takeaways
  8. 3 practical use cases for your work
  9. One-line summary for proposals

1What's actually changing

Polaris reference documentation has been unified underthe same versioning policy as Shopify's GraphQL API.
Each stable version issupported for at least 12 months.Starting with the 2026-04 release, only the four most recent stable versions will have documentation published on Shopify.dev.
ALL VER.

Before: docs for all versions published

References for older stable versions used to remain on Shopify.dev indefinitely.

4

New policy: only the latest 4 versions

At least 12 months of support, with only the 4 most recent stable versions published. Anything older is removed from docs.

Important: "the docs go away" does not mean "it stops working."The post clearly states "Older versions continue to work." Only the dedicated reference on Shopify.dev is removed.

2How it works: versions and documentation coverage

Newer → Docs coverage: the 4 latest stable versions (at least 12 months of support) Old v No docs / Works ◯ Old v No docs / works OK v -3 v -2 v -1 Latest ← CLI blocks deploys targeting versions beyond this point (older than 12 months)
Documentation removal and deploy eligibility are designed to move in lockstep.Shopify CLIalready blocks deploys targeting API versions older than 12 months. In other words, by the time the docs are gone, you can no longer deploy either. Shopify recommends staying on a supported version.

* The article's wording that "only the most recent 4 versions are published" aligns with the policy that "each stable version is supported for at least 12 months" (the article notes this matches the same policy as Shopify's GraphQL API). The article does not specify whether old docs are removed immediately or in stages.

3The 4 UI extension docs affected

The references that the article explicitly states will "only publish the most recent 4 stable versions" are these 4:

Admin UI extensions
Admin extensions
Checkout UI extensions
Checkout extensions
Customer account UI extensions
Customer account extensions
POS UI extensions
POS (in-store) extensions

4Old vs. new policy comparison

ItemPreviouslyNew policy (from 2026-04)
Documentation coverage Broad Docs for older versions also remained Most recent 4 Last 4 stable versions only
Versioning policy Per-product Unified Same as the GraphQL API
Support period Not explicitly stated At least 12 months Per stable version
Behavior of older versions Works Works (only the docs disappear)
Deploys to versions older than 12 months Not allowed Shopify CLIalreadyblocks them (since before this change)

5Cases affected / not affected

Impact

Maintaining extensions pinned to old versions

If you're referencing a stable version older than 12 months, the documentation will disappear from Shopify.dev in the near future and you won't be able to look up the reference. On top of that, the CLI already blocks deploys beyond that window.

Impact

Old docs URLs pasted in internal materials

Reference URLs outside the most recent four versions may become unreachable at some point. Risk of broken links in bookmarks and wikis. (The article doesn't specify exactly when removal happens.)

No impact

Operating on supported versions

As long as you maintain extensions on the latest four stable versions (roughly within the last 12 months), the docs and deploys keep working as before.

No impact

The running old extensions themselves

As stated, "Older versions continue to work" — thebehaviorof old-version extensions doesn't stop. This change is strictly about the scope of published documentation.

6Actions engineers should take (3 steps)

1

Inventory your extensions' target versions

List the API version each extension (Admin / Checkout / Customer account / POS) references.

2

Update to a supported version within 12 months

Bump versions so they fall within the latest four stable versions. The article recommends this too.

3

Build periodic updates into your operations

Build a quarterly version check into your calendar or CI to preempt docs disappearing and deploy blocks.

Shopify CLI alreadyblocksdeploys older than 12 months, so treating "CLI deploy succeeds = within supported range" makes the call quick.

75 points engineers should keep in mind

= GraphQL

1. Same policy as the GraphQL API

Polaris reference docs are now aligned with Shopify's GraphQL API versioning policy. Each stable version is supported for at least 12 months. You can think about API and extension versioning on the same yardstick.

2. Behavior doesn't stop

What disappears is just thededicated documentationon Shopify.dev. The old-version extensions themselves continue to work (backward compatibility is preserved).

3. CLI blocking is already in place

Shopify CLIalreadyprevents deploys to API versions older than 12 months. Nothing newly breaks with this docs change — the policy has simply been made explicit.

4. Publication is limited to "the last four stable versions"

Starting with the 2026-04 release, only the last four stable versions will be published. Understand this as the range that aligns with the support window (at least 12 months).

5. Targets four types of UI extension docs

The references for Admin UI / Checkout UI / Customer account UI / POS UI extensions are all affected. Projects that use multiple types need to manage version tracking separately for each.Watch out for broken links if you've pasted old docs URLs into internal materials(The article does not specify the exact deletion timing).

8Three use cases you can apply to your work

Multi-client extension
USE CASE 1

Operationalize "extension version tracking" as a rule at agencies

Problem
You maintain extensions for multiple clients, and the target API version varies by project. Old ones eventually lose their documentation, making it impossible to look up the spec during maintenance.
Approach
Inventory the target versions of all extensions and set up a regular maintenance window to align them with the four most recent stable versions (roughly within 12 months).
Outcome
Keeps documentation accessible while avoiding CLI deploy blocks. Maintenance effort estimates stay stable.
Technical notes
Since Shopify CLI already blocks deploys older than 12 months, "whether the deploy goes through" serves as a simple check for being within the supported range.
USE CASE 2

Preventing broken links in internal knowledge bases / bookmarks

Problem
Team Wikis and runbooks link to Polaris/UI extension documentation URLs for specific versions. When old version docs go out of publication scope, there is a 404 risk.
Approach
Swap reference links to the latest (version-agnostic) docs, and clearly note in your knowledge base that "only the four most recent stable versions are published."
Outcome
Prevents broken links and references to outdated specs. Keeps onboarding materials for new hires fresh.
Technical notes
The article does not detail when old docs are removed. It's safer to proactively audit your links ahead of time.
12-month window Quarterly check
USE CASE 3

Build it into upgrade plans for long-running stores

Problem
On replatformed or long-running stores, extension versions stay pinned to old versions. Left alone, you'll face documentation loss plus future deploy blocks.
Approach
Build quarterly API/extension version audits into your operations calendar and CI, and update before falling outside the support window (the four most recent versions).
Outcome
Planned upgrades prevent the "by the time we noticed, both docs and deploys were stuck" scenario. Makes risk visible.
Technical notes
Since this follows the same versioning policy as the GraphQL API, you can unify the management cycle for API versions and UI extension versions.

9One-line summary you can use in proposals

"Polaris UI extension documentation is now unified under the sameminimum 12-month support, only the four most recent stable versions publishedpolicy as the GraphQL API.
Old extensions keep working, butthe documentation goes away, so keep your extensionson a supported version within the last 12 monthsis the safe approach.
Since the CLI already blocks deployments to outdated versions, it's enough to make periodic version updates part of your operational routine."