Product Decisions This Supports
- Platform upgrade sequencing (Statamic 6): The 3.0.5 release adds Statamic 6 support, which removes a hard dependency blocker from the CMS major-version upgrade. This directly informs when the Statamic 6 migration can be scheduled rather than whether it is feasible.
- Build vs. buy for the integration layer: The package is the connective tissue between our Laravel application and Statamic. Its compatibility cadence is a factor in the keep-vs-replace decision — a vendor that ships major-version support promptly is cheaper to retain than to reimplement.
- Dependency standardization and version pinning policy: Because the compatibility landed in a patch release (3.0.5) rather than a minor/major, we can decide whether to float on
^3.0 or pin precisely, and how much upgrade risk we accept from patch-level changes to compatibility claims.
- Roadmap risk register: Maintaining current support for the newest Statamic major reduces the risk of being stranded on an unsupported CMS branch, which affects our support-window and security-patching commitments.
- Release-gating criteria for our own work: Establishes a concrete checklist item — "downstream addon declares Statamic 6 support with a passing test matrix" — that product can use as a go/no-go signal for the upgrade epic.
When to Consider This Package
Adopt or retain when:
- The product runs on Statamic and is planning or executing a move to Statamic 6; without a compatible addon the upgrade path is blocked or requires a fork.
- The team wants an actively maintained Laravel/PHP integration rather than an internal implementation with no upstream support.
- The package's supported matrix (Statamic 6 × Laravel × PHP versions) overlaps our own runtime matrix, and the upgrade can be validated with the existing test suite.
Look elsewhere, or treat as insufficient on its own, when:
- The application is not on Statamic — the release note carries no value to a plain Laravel stack.
- The 3.0.5 change is a compatibility declaration only, with no evidence of CI coverage against Statamic 6. Verify the test matrix before treating it as a green light.
- We need guaranteed support windows (LTS), SLAs, or vendor indemnity — a community-style package release cadence does not supply these.
- The 3.x line carries breaking changes we have not absorbed; a patch bump to 3.0.5 assumes we are already on 3.x. Teams still on 2.x should scope the 2.x → 3.x migration separately before counting this as an upgrade enabler.
- Core functionality is trivial to replicate in-house — a thin wrapper is not worth the dependency surface.
Caveat: this assessment is derived from a single-line release note ("Statamic 6 support"). Before committing roadmap dates, confirm the composer constraints, the CI matrix, and whether any behaviour changed for existing Statamic 5 users.
How to Pitch It (Stakeholders)
To executives: A patch release (3.0.5) has added support for the newest version of Statamic, the CMS our Laravel application depends on. In practical terms this unblocks a platform upgrade we would otherwise have had to defer or work around. The cost is a routine dependency bump, not a re-platforming exercise, and the vendor is demonstrably maintaining the package against current upstream releases — which lowers our long-term maintenance exposure. Recommended ask: approve scoping the Statamic 6 upgrade for the next planning cycle, contingent on engineering validating the package's test coverage.
To engineering: Version 3.0.5 declares Statamic 6 support. Confirm the composer version constraints actually permit Statamic 6 alongside our Laravel and PHP versions, run the full suite against a Statamic 6 branch, and review the 3.x changelog for breaking changes if we are not already current on 3.x. Treat this as a compatibility signal, not a substitute for our own regression testing — the release note does not describe behavioural changes or expanded test coverage.