Statamic Laravel Packages Laravel Package

Product Decisions This Supports

• Roadmap sequencing for the CMS upgrade: release 1.0.4 adds Statamic 3.4 composer.json support, which is the gating item for any planned Statamic 3.4 migration. This directly informs whether the Statamic upgrade ships this quarter or slips.
• Build vs. buy: the package carries Statamic compatibility metadata that would otherwise be maintained in-house. Each upstream Statamic minor version you adopt without this package is a fork or a patch you own — a recurring maintenance cost line.
• Dependency risk register: a composer-constraint-only change signals the maintainer is tracking upstream releases. That is a leading indicator of project health and belongs in vendor/abandonment risk tracking alongside commit cadence and issue responsiveness.
• Feature scoping: 1.0.4 contains no user-facing functionality, so it should not be sold internally as a capability. It is an enabler — scope it under "platform currency," not under the product backlog.
• Release timing decisions: because the change is confined to composer.json, it is safe to bundle into a routine dependency bump rather than a dedicated release train, freeing sprint capacity for feature work.

When to Consider This Package

Adopt when:

• You are on Statamic 3.4 (or planning to move there) and need a Laravel/PHP package whose composer constraints resolve cleanly against it. Before 1.0.4, this likely required a --ignore-platform-reqs workaround or a pinned fork.
• You want the Statamic integration maintained externally rather than owned by your team.
• Your dependency policy requires explicit upstream compatibility declarations rather than loose version ranges.

Look elsewhere or defer when:

• You are on Statamic 2.x, 3.0–3.3, or 4.x — this release explicitly targets 3.4, and no statement is made about other lines.
• The package's remaining surface area is thin enough that a few dozen lines of in-house glue code is cheaper than a dependency.
• You need guarantees this release does not provide: there is no indication of test coverage expansion, security review, or a documented support window. A composer-only patch is evidence of maintenance, not of robustness.
• Verification gap: no release data was supplied beyond the changelog line. Confirm the actual constraint change, that CI runs against Statamic 3.4, and that no transitive dependency floors moved before committing to the upgrade path.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk maintenance release. Its business value is unblocking our Statamic 3.4 upgrade — it removes a dependency conflict that would otherwise force us to fork or patch the integration ourselves. No new functionality, no migration work, no user-visible change. Cost of adoption is a routine composer update; cost of skipping it is carrying a forked dependency through the CMS upgrade.

To engineering: Version 1.0.4 updates the Statamic 3.4 composer.json declaration. Expect a constraint change and nothing else — review the diff, confirm CI covers 3.4, then fold it into the next dependency bump. Low blast radius, but verify transitive constraints before merging so the upgrade doesn't surface a conflict later in the cycle.