Statamic Flexible Width Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing (primary): Release 2.0.0 signals that this package now supports Statamic 6. This should be treated as a dependency-readiness signal in the Statamic 6 migration plan — it unblocks the "can we move the CMS major version yet?" question for any product surface that depends on this package.
• Build vs. buy: If the package's capability (whatever Statamic extension it provides) is on the roadmap, the fact that it has an actively maintained Statamic 6–compatible line reduces the case for building and maintaining that functionality in-house through the upgrade.
• Roadmap gating and version pinning: A major version bump is a hard fork in the dependency graph. The PM decision is not "should we adopt the feature" but "which of our products/environments pin to 1.x, which move to 2.x, and in what order." Expect 1.x to become a maintenance-only line.
• Release-note scope caveat: The 2.0.0 notes list only Statamic 6 support. No new end-user features, no deprecations, no API changes are described. Treat this as a compatibility release until the changelog, README, and upgrade guide are reviewed — do not market it to stakeholders as a feature win.
• Risk register entry: Major-version bumps on a CMS-adjacent package are a common source of silent breakage (config formats, template tags, service provider bindings, publishable assets). Budget QA time proportional to how deeply the package is embedded in the content model.

When to Consider This Package

Adopt or upgrade when:

• You are already on Statamic and are planning or executing a Statamic 6 migration — 2.0.0 is the version you need, and 1.x is the version you must leave behind.
• The package is already in the stack and currently pinned to 1.x: this release is your migration trigger, and the work should be scheduled alongside the Statamic 6 upgrade rather than after it.
• You need a maintained dependency rather than a fork — an author shipping a Statamic 6 line is a reasonable proxy for ongoing stewardship.
• Your team can absorb a major-version upgrade as a discrete, testable change with a rollback path.

Look elsewhere or defer when:

• You are not on Statamic, or are staying on Statamic 5 for the foreseeable future — 2.0.0 delivers no value on that path, and 1.x should be treated as frozen.
• You are greenfield and evaluating the package for the first time: the 2.0.0 notes contain no capability description, so the evaluation must be done against the package's documentation and a spike, not against this release.
• The package occupies a critical path in your content pipeline and you cannot tolerate a breaking major-version upgrade this cycle.
• The underlying need is narrow enough to be met by Statamic core or first-party add-ons, which carry lower long-term dependency risk.

How to Pitch It (Stakeholders)

For executives (one paragraph): A dependency in our Laravel/Statamic stack shipped a major release, version 2.0.0, adding support for Statamic 6. This is not a feature release — it is an upgrade-readiness release, and it is the gate that determines whether our planned CMS major-version migration can proceed on this dependency's timeline. The decision it enables is scheduling, not scope: we now have a supported path to Statamic 6 for this component. The cost is a planned, testable upgrade with a rollback option, not a net-new project. Recommend we slot the upgrade into the existing Statamic 6 migration workstream and confirm the 1.x support window with the maintainer.

For engineering (bullets): Major version bump — assume breaking changes despite the terse notes; read the changelog, upgrade guide, and diff before touching our pins. Verify service provider registration, config publishing, and any template/API surface we consume. Pin explicitly to 2.x only after the Statamic 6 upgrade lands in a branch; keep 1.x available for rollback. Add a smoke test around the package's integration points if one doesn't exist — this release is exactly the kind of change that fails quietly. Confirm the maintainer's support policy for 1.x so we know our deadline.

Open questions to resolve before committing: What is the 1.x end-of-life date? Are there breaking changes beyond the Statamic 6 requirement? Does 2.0.0 drop support for older PHP or Laravel versions that we still run anywhere? None of these are answered by the release notes as published.