EDITIONS · PLATFORM · OPERATIONS · 18 NOVEMBER 2025 · 7 MIN READ
Winter Edition planning: what to test before you commit
The Edition lands in the new year. The useful preparation is a place to test things, not a list of things to adopt.
Evaluate a Shopify release by testing it against your own store before you commit anything to a roadmap. Most merchants read an Edition, pick the features that sound relevant, and put them in a quarter — which is a decision made on a paragraph of marketing copy. The better sequence is to have somewhere safe to try things first: a development theme, a store you can break, an API version you have deliberately pinned, and a short list of decisions you are already making. Then a feature either changes one of those decisions when you try it, or it does not, and you have an answer rather than an opinion.
IN SHORT
- An Edition is a changelog wrapped in marketing; read it against decisions you are already making rather than as a list to work through.
- Anything labelled early access, developer preview or unstable is planning information, not build information.
- Shopify releases a new API version every three months at 5pm UTC on the first day of the quarter, and supports each stable version for a minimum of twelve months — so a platform change almost never has to be absorbed in the same week it appears.
- A development theme is free, hidden and deleted after seven days of inactivity, which makes it the cheapest possible place to test a theme-level feature.
- Test with your own catalogue and your own traffic patterns; a feature that behaves well on a demo store with twelve products can behave differently on forty thousand.
- The strongest reason to adopt something is that it replaces a custom mechanism you are currently paying to maintain.
What an Edition is, and what it is for
Shopify publishes an Edition twice a year, one in summer and one in winter, collecting several hundred changes into a single themed release with a name. Summer ’25 was Horizons; Winter ’25 was Boring; Summer ’24 was Unified. Individual features ship continuously through the developer changelog all year — the Edition is the periodic collected view, and the marketing moment.
Both of those jobs are real, and they pull against each other. Volume is the point of the marketing: several hundred items signals a platform moving quickly. Volume is the enemy of the changelog, because the six things that matter to you are buried among the several hundred that do not.
This is why the reading strategy matters more than the reading. Going through an Edition top to bottom produces a list of interesting features and no decisions. Going through it with two or three live questions — we are re-scoping the theme, we are about to buy a returns app, we are opening in Germany — produces a much shorter list where every item is attached to something you were going to have to decide anyway.
Set up the test bench before the Edition, not after
The reason most merchants commit to features on a paragraph of copy is that trying one properly takes a day of setup they have not done. Do the setup in advance and the cost of evaluating a feature drops to an afternoon.
Four things are worth having standing:
- A development store with a realistic catalogue. Not twelve products — a copy of the shape of your real one, with the metafields, the variant counts and the collection sizes you actually have. Most surprises in a platform feature are volume surprises.
- A development theme you can push to. Shopify CLI creates these as temporary hidden themes that do not count against your theme limit and are deleted after seven days of inactivity, so there is nothing to clean up.
- An unpublished theme for anything a stakeholder needs to see.
shopify theme push --unpublishedcreates a new one and pushes to it; the preview is password-protected and does not touch the live store. - A pinned API version for every integration you own, plus a note of which one. Nothing about a platform release should be a surprise to a system you control.
Time is on your side, and the version policy says so
The anxiety an Edition produces — everything changed, we are behind — is mostly manufactured by the format. The platform’s own release policy says otherwise.
Shopify ships a new API version every three months, at 5pm UTC on the first day of the quarter. Each stable version is supported for a minimum of twelve months, with at least nine months of overlap between consecutive versions. That is a deliberately generous window, and it exists so that nobody has to rebuild an integration in a hurry. If a change to an API affects you, you have three quarters of overlap in which to move.
The same documentation is equally clear about the other end of the scale. The unstable version is "updated continuously with in-progress changes", features "can be added or removed at any time with no guarantee of release", and it is for early testing only. A release candidate ships on the same date as the stable version and may include backwards-incompatible changes. Neither is a foundation for a project with a launch date.
So the honest position on anything marked developer preview or early access in an Edition is: put it on the watch list, do not put it in a quote. Scoping around a preview means inheriting somebody else’s release schedule, and you will not be told when it slips.
Five questions to ask of any feature in the release
When something in the Edition does look relevant, these five questions get to an answer faster than a discovery workshop.
- Does this replace something we already pay for or maintain? An app subscription, a custom Liquid mechanism, a scheduled script. This is the strongest possible reason to adopt, because it removes something as well as adding something.
- Is it shipped, or announced? If the Edition does not say generally available, treat it as a date you do not control.
- What breaks if we turn it on and then turn it off? Reversibility is worth more than fit. A feature you can unwind in an afternoon can be tested in production on a fraction of traffic; one that rewrites your data cannot.
- Who operates it after launch? A feature that needs somebody to curate it weekly needs a named somebody, or it decays into a half-configured setting that confuses the next agency.
- Does it behave at our volume? Test with your catalogue, your order rate and your peak, not the demo data.
What to do with the vendor’s numbers
Editions carry performance claims — a faster checkout, a faster admin, a better conversion rate on some surface. These are the vendor’s own measurements of the vendor’s own products, published in a marketing document. That does not make them false. It makes them unverifiable by you, which is a different problem and a worse one if the number ends up in a business case.
Treat a vendor figure as a direction to check against your own data. If checkout got faster, it shows up in your funnel and you own those numbers. If a template got faster, Shopify’s own web performance reports in the admin will show it — they report Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift from your real traffic, per page. That is a measurement you can defend in a meeting because you can reproduce it.
Counts are different from percentages. "Shopify Payments is now available in sixteen more countries" is a precise, checkable claim, and it matters only if one of the sixteen is yours. Read the list, not the total.
The posture that makes every Edition easier
Read three or four of these in a row and the direction is consistent: the platform absorbs things merchants used to buy apps for, and moves customisation out of theme code into blocks, extensions and functions with defined boundaries. Both are good news if your store sits close to platform defaults, and bad news if your competitive advantage is a clever workaround in a template.
Which means the right response to an Edition is usually not to adopt anything. It is to keep the store in a state where, when the platform ships the thing you were about to pay for, you can simply switch it on. Every bespoke mechanism you carry is a future migration.
We scope [Shopify builds](/services/build) that way deliberately: fewer apps, fewer custom mechanisms, more of the store expressed in the parts of the platform Shopify is actively investing in. It makes the twice-yearly reading shorter, and it makes most of what you do read something you can test in an afternoon rather than something you have to plan a quarter around.
Questions this raises
When is the Shopify Winter Edition released?
Shopify publishes two Editions a year, summer and winter, with the winter one landing early in the calendar year. Shopify does not commit to a fixed date in advance, so the practical answer is to have your test setup ready rather than to plan around a date. Individual features ship continuously via the developer changelog regardless of the Edition schedule.
How should we decide which Edition features to adopt?
Read the release against the decisions you are already making, not as a list to work through. Adopt the items that replace something custom you currently pay for or maintain, note the ones marked early access for a later review, and ignore the rest until something in your own backlog makes them relevant. A feature with no decision attached to it is not a roadmap item.
Do we need to act on a Shopify API change immediately?
Almost never. Shopify releases a new API version every three months and supports each stable version for a minimum of twelve months, with at least nine months of overlap between consecutive versions. That gives you three quarters to move an integration deliberately. What you do need is to know which version each of your integrations is pinned to, because an unpinned integration is the one that breaks without warning.
Where should we test a new Shopify feature?
On a development store with a realistic catalogue, and for theme-level changes on a development theme created by Shopify CLI. Development themes are hidden, do not count against your theme limit and are deleted after seven days of inactivity. For anything a stakeholder needs to look at, push to an unpublished theme instead — the preview is password-protected and the live store is untouched.
Should we build on a feature marked developer preview?
Not if the project has a launch date. Shopify is explicit that preview and unstable surfaces can change or be withdrawn without notice, and a release candidate may include backwards-incompatible changes. Previews are worth prototyping against so you know what is coming; they are not worth committing a delivery date to.
Are the performance figures in an Edition reliable?
They are the vendor measuring its own products, which is a reasonable thing to publish and a poor thing to put in a business case. Use them as a signal to look at your own data instead. Shopify’s web performance reports in the admin give you page-level Core Web Vitals from your own traffic, which is a number you can reproduce and defend.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.