Shopify moved the Polaris CDN onto semantic versioning on August 31, 2026, and published a 1.1 release candidate the same day. For any team loading Polaris Web Components from Shopify's CDN, the version running in production is now a decision rather than whatever Shopify pushed overnight. Most app teams should take the pin.
What changed on August 31
The Polaris CDN now ships on semantic versioning, with distinct URLs for stable, pinned and release candidate builds. Major releases carry breaking changes and require developer action, minor releases carry compatible improvements and fixes, and security patches apply to stable releases across versions, per the Shopify developer changelog. The @shopify/polaris-types package now aligns its version numbers with the CDN builds, so type definitions and runtime stop drifting apart. The scope is narrower than the headline suggests. It covers third party apps loading Polaris Web Components from the CDN. App Home UI extensions, Admin UI extensions and App Bridge versioning are unchanged.
Pinned vs stable: which Polaris URL belongs in production
Pin production to an explicit minor, point staging at the release candidate, and leave nothing on the legacy URL. There are three channels and they behave differently. The stable channel at polaris-1.js picks up minor releases automatically and stops at the major boundary, so it will not carry you into 2.x on its own. A pinned build at polaris-1.1.js does not move at all. The release candidate at polaris-1.1-rc.js collects fixes during the testing window before that minor goes stable. The legacy polaris.js updates alongside the stable channel and also will not cross a major.
The tradeoff is ownership of timing. On the stable channel, a vendor release can change how a component behaves inside a merchant-facing admin app on a Tuesday morning, with no ticket, no diff and no rollback path you control. Pinned, that cannot happen, and the price is that you now own the upgrade cadence and have to schedule it. For a studio shipping under contract, that price is the point. One boundary deserves care: security patches apply to stable releases, so a production app parked on a release candidate is sitting outside patch coverage. Release candidates belong in staging, never in production.
What the 1.1 release candidate actually adds
Two components, four properties and one deprecation. EmptyState covers empty lists, tables and pages. Number renders inline numeric text using tabular figures, so columns of figures line up. A fontSize property lands on Heading, Paragraph and Text. DatePicker gains visibleMonths, which accepts auto, 1 or 2. Page gains supplementalStart for extra content placement. The fix list runs across overlays, Modal, Popover, Menu, Tooltip, DatePicker, Select, NumberField, TextField, DateField and ColorPicker, per the 1.1 release candidate notes. Opting in is a one line change to the release candidate script URL.
The deprecation is the part worth reading twice. fontVariantNumeric on Text and Paragraph is deprecated in favour of the new Number component. On its own that is a small ergonomic improvement, tabular figures becoming a component rather than a property. Structurally it is the first visible proof that the versioning policy has teeth. A property deprecated in a 1.x minor is a property that can be removed at 2.0, and under the new rules 2.0 will not reach you automatically on any of the channels above. That is the whole value of the change. The breaking release becomes something you schedule.
What we would change this quarter
Audit which Polaris URL every app you own is loading, pin production to an explicit minor, and wire the release candidate into your staging build. For most app estates that is half a day of work, and it converts an uncontrolled dependency into a scheduled one. If you ship the types package alongside, move it to the matching version in the same commit, because the benefit of aligned versioning disappears the moment the two diverge. We treat vendor design systems the way we treat runtime versions on every Shopify Plus and Magento build. The version is part of the deliverable, not part of the weather.
Then be precise about what versioning does not buy you. Shopify stops injecting script tags into storefronts on March 1, 2027, and that deprecation applies to all API versions including older ones, so pinning does not defer it, per the script tag deprecation notice. The replacement is an app embed block shipped in a theme app extension, which merchants activate in the theme editor. Pinning controls the shape of an API you keep. It does nothing about an API being withdrawn. Both items belong on the same Q4 list and they need different treatments. One is a version number you choose. The other is a migration with a hard date, the same shape as the checkout extensibility deadline. The teams that handle this well keep one dated register of every third party surface their product and design system work depends on, with the channel and the expiry written beside each entry.