Antlers Layouts Laravel Package

Product Decisions This Supports

• CMS platform upgrade sequencing (Statamic 5 → 6): v2.1.1's headline change is Statamic 6 compatibility, which makes this package a gating item in the upgrade plan rather than a feature decision. PM action: confirm whether the addon is on the critical path for the Statamic 6 migration and slot it into the upgrade runbook before committing a launch date.
• Build vs. buy for CMS-adjacent functionality: a package that tracks upstream Statamic releases (v2.1.1 landing shortly after Statamic 6) demonstrates maintenance velocity. That lowers the "build in-house" case for whatever capability it provides and raises the "buy/adopt" case, since keeping parity with the CMS is a recurring cost the maintainer is absorbing.
• Roadmap risk and dependency mapping: any feature that depends on this addon now inherits a minimum platform version constraint. Product must decide whether to (a) hold features until Statamic 6 is certified, (b) support dual versions (Statamic 5 and 6) for a transition window, or (c) drop Statamic 5 support and force upgrades across client sites.
• Multi-tenant / multi-site portfolio planning: if the product runs several Statamic sites, a version-locked addon segments the portfolio. This informs whether to standardise all sites on one Statamic major version or run a mixed fleet with per-site upgrade budgets.
• Use cases it unlocks: editorial/content features delivered through the addon become shippable on Statamic 6 environments — relevant for content-team-facing roadmap items, not end-user consumer features.
• Support and SLA exposure: upgrading to Statamic 6 while relying on a package that has only just added support means the earliest adopters are the de facto testers. PM should budget a soak period before promising Statamic 6 availability to customers.

When to Consider This Package

Adopt when:

• Your stack is Laravel + Statamic, and you are planning or actively executing a Statamic 6 migration — v2.1.1 is the version that makes the addon viable on the new major.
• The capability it provides is non-differentiating for your product (standard CMS/editorial plumbing). Purchasing maintenance velocity from a maintainer who ships upstream-compat releases quickly is cheaper than owning it.
• You need a maintained dependency: the v2.1.1 release is a positive signal that the package is actively kept in step with the CMS.
• You are standardising a portfolio of Statamic sites and want a single dependency set across them.

Look elsewhere or defer when:

• You are staying on Statamic 5 for the foreseeable future — you gain little from this release and take on churn risk from a fast-moving compatibility line.
• The addon sits on a critical path with no fallback and the maintainer is a single person or a small team; the Statamic 6 support arriving only at v2.1.1 (i.e. after Statamic 6's own release) means your upgrade is coupled to their schedule.
• The functionality is core to your differentiation — in that case, own it and control the upgrade cadence yourself.
• You need documented long-term support guarantees; patch-level releases like 2.1.1 rarely come with an LTS commitment, so verify versioning/support policy before committing.

How to Pitch It (Stakeholders)

For executives (one paragraph): We depend on a Laravel/Statamic addon that has just shipped v2.1.1, adding support for Statamic 6. In plain terms: the vendor has kept pace with the CMS's new major version, so our planned platform upgrade is no longer blocked by this dependency. There is no new feature to sell and no breaking change to manage — the value is continuity and reduced migration risk. The decision on the table is timing: whether we sequence our Statamic 6 upgrade now (early-adopter risk, minimal support history on the new major) or wait one or two patch releases for the integration to settle.

For engineering: v2.1.1 is a compatibility release — Statamic 6 support is the only change called out. Treat it as a green light to begin Statamic 6 upgrade work in a branch, not as a signal to ship to production immediately. Please confirm: (1) whether the upgrade is a hard requirement or the package supports Statamic 5 and 6 concurrently, (2) whether any of our code touches internals this addon depends on, and (3) a soak plan — staging environment, regression pass on editorial workflows, and a rollout window that does not coincide with a content freeze. Flag anything in the release that is undocumented; the notes are terse and we should read the actual diff before we commit a date.