editions recap: the five areas that matter for plus merchants.

How we sort a Shopify Editions release, the five areas that matter for Plus merchants running custom apps and integrations, and the ones you can safely ignore.

  • EVENT
  • updated
  • by lead.themes
  • recap

Shopify Editions arrives twice a year with a very long list of announcements. Most of them are real, some are early previews, and only a few will change what a Plus engineering team does in the next two quarters. This recap is how we read the list, and where we look first.

how do you read an editions release?

We sort every announcement into one of four piles before we have an opinion about it.

  • Changes your code. Deprecations, API changes, checkout and Functions updates. These get a ticket.
  • Replaces something you pay for. Native features that overlap an app or a custom build. These get a cost comparison.
  • Available to you now. Generally available features you can switch on. These get a look on a dev store.
  • Preview or roadmap. Developer previews, early access and “coming soon”. These get a note and nothing else until they ship.

The last pile is usually the biggest, and it is the one that generates the most noise. A preview can change shape or be withdrawn before general availability. Do not plan a build around it.

which five areas matter for plus merchants?

For Plus merchants running custom apps and integrations, the announcements worth acting on almost always sit in the same five areas. The specific items change every release; where to look does not.

  1. Checkout extensibility. New extension targets and components, changes to the APIs extensions call, and deprecations with a removal date.
  2. Shopify Functions. New function APIs, changed limits and input queries, which decide what discount, delivery and payment logic can move out of an app.
  3. The Admin API. New fields and types, and the deprecations that will become removals in a later version.
  4. B2B. Catalogs, price lists, quantity rules and company accounts, which decide how much wholesale logic can be native.
  5. Admin tools merchants use every day. Flow, bulk editing and reporting changes that can retire a script or a manual task.

We have written up the areas that need engineering work separately:

what you can safely ignore

  • Anything marked as a developer preview, unless you are prepared to rebuild when it changes.
  • Features aimed at new or small merchants, such as setup flows and starter tooling. Useful, but not for a mature Plus store.
  • Design and theme announcements, if your storefront is headless or heavily custom. Read them, but they rarely apply as written.
  • Anything you cannot find in the changelog or the developer docs. If it is only in the keynote, it is not ready.

who it touches

Every Plus merchant gets the same list. What it means depends on how much custom code you run. A stock store can read the merchant summary and stop. A store with checkout extensions, functions, private apps or an ERP integration should treat Editions as the start of a short engineering review.

what we’d do

  1. Sort the list into the four piles above, in an hour, with one engineer and one person who owns the store.
  2. Open tickets for the first pile, each with a deadline if a deprecation is involved.
  3. Price the second pile against what you pay today.
  4. Try the third pile on a dev store before switching anything on in production.
  5. Revisit the fourth pile at the next Editions, not before.

checklist

  • Announcements are sorted into code, replace, available and preview.
  • Anything that changes your code has a ticket with a deadline.
  • Anything that overlaps a paid app has a cost comparison.
  • New features are trialled on a dev store before they are enabled.
  • Previews are parked until they ship.

impact

Recap. No action from this entry alone. The linked entries carry the action items.