Statamic Buddy Laravel Package

Technical Evaluation

Scope caveat: the supplied record contains no prior assessment and an empty data set, so no package identity, repository, install base, or version history is available. This evaluation is grounded strictly in the v2.0.0 release note — a single breaking change removing Statamic 3 support — and should be re-run once the package manifest and composer.json constraints are attached.

• Architecture fit. The only architectural signal here is a hard compatibility boundary pinned to a CMS major version. A package that drops Statamic 3 wholesale is tracking upstream majors rather than maintaining a wide support band. For a TPM this is a predictable architecture: version N of the package maps to a known Statamic generation, which makes dependency reasoning cheap and makes the support matrix documentable in one line.
• Integration feasibility. Removal of Statamic 3 support should surface as a Composer constraint change (statamic/cms floor moving to ^4.0 or ^5.0, or an equivalent conflict/require edit). That produces an install-time resolution failure on Statamic 3 hosts rather than a runtime failure — the desirable failure mode. Integration into a Statamic 4/5 application is therefore mechanically trivial; integration into a Statamic 3 application is blocked by design, not merely discouraged.
• Technical risk. Three exposures. First, orphaned consumers: any application left on Statamic 3 is now frozen on the package's 1.x line, receiving no fixes, no security patches, and no compatibility work for future Laravel/PHP releases. Second, release-note sufficiency: a major version bump justified solely by a support drop usually implies no runtime changes, but the note does not assert that. If v2.0.0 also carries internal refactors, template/tag behavior, fieldtype output, or config defaults, a consumer bumping the constraint would take those silently. Third, transitive floors: Statamic 4 and 5 raise PHP and Laravel minimums (roughly PHP 8.1 and 8.2 respectively), so the effective runtime floor for the host application moves even though this package did not say so.
• Key questions. (1) Which package and repository is this, and what does the composer.json diff for v2.0.0 actually contain? (2) Is the 1.x line still receiving security fixes, and for how long — is there a published EOL date? (3) Is the v2 support matrix Statamic 4 only, 5 only, or both? (4) Does the CHANGELOG or diff show any change beyond the constraint edit? (5) How many services in our estate currently resolve Statamic 3?

Integration Approach

• Stack fit. Statamic 3 is end-of-life upstream, so the package dropping it is alignment with the vendor, not a unilateral tightening. Any Laravel/Statamic estate that is already on Statamic 4 or 5 fits cleanly and this bump is a low-risk patch-equivalent. Estates still on 3 do not fit, and no amount of package-side work will make them fit.
• Migration path. Do not attempt to bump this package in isolation — Composer will hard-fail and the error will be read as "the package is broken" rather than "the CMS is old." The correct order is: upgrade the host application's Statamic major first (3 → 4, then 4 → 5 if targeting current), then bump this package's constraint. Treat the package bump as the last step of a CMS upgrade, never as the trigger for one.
• Compatibility. Verify the host application's PHP and Laravel versions against the Statamic target before scheduling anything; Statamic 4 and 5 move those floors, and the Laravel upgrade is frequently the larger of the two work items. Also confirm no other installed package pins statamic/cms to ^3.0, which would create an unresolvable diamond and force a coordinated multi-package upgrade.
• Sequencing. (1) Inventory every composer.lock in the estate for statamic/cms and this package; classify into "already 4/5," "on 3," and "not present." (2) For the "on 3" cohort, scope the Statamic upgrade as its own project with its own estimate — this is the only real cost in the entire change. (3) In a branch, upgrade Statamic, then bump this package, then run the full regression suite. (4) Prioritize regression coverage on control-panel customizations, Antlers templates, and any custom fieldtypes, since those are where a Statamic major upgrade historically breaks. (5) Ship the "already 4/5" cohort immediately — for them this is a routine dependency refresh.

Operational Impact

• Maintenance. For the package maintainer, one fewer major to support is a straightforward reduction in CI matrix size and branch overhead — a good sign for the package's long-term health. For us, the operational consequence is inverted: our 1.x-pinned environments transition from "maintained" to "frozen" on the release date, and that transition is invisible unless someone records it.
• Support. Consumer-facing support burden concentrates on the Statamic 3 cohort. Expect internal tickets of the form "cannot install the new version" that are actually "this application is two CMS majors behind." Pre-empt these with a written position: Statamic 3 applications are pinned to 1.x, no exceptions, upgrade path is the remediation.
• Scaling. Not a throughput or capacity concern. The scaling dimension that matters is estate breadth: the cost of this release scales linearly with the number of applications still on Statamic 3, and each one carries the full weight of a CMS major upgrade. A single-app estate may see zero impact; a twenty-app estate may see a multi-quarter program.
• Failure modes.
  • Loud and safe: Composer refuses to resolve on Statamic 3. Detectable in CI, cheap to diagnose.
  • Silent and costly: v2.0.0 contains undocumented runtime changes alongside the support drop, and a Statamic 4/5 consumer bumps the constraint as a "routine" update and absorbs behavior changes without scrutiny. Mitigate by reading the actual diff rather than trusting the note.
  • Deferred and compounding: Statamic 3 applications accumulate on a frozen dependency while their Laravel and PHP versions also age out of security support, converting a CMS upgrade into a full platform upgrade eighteen months later.
  • Diamond conflict: a third-party package still requiring statamic/cms ^3.0 blocks both the Statamic upgrade and this bump, and the blocker must be replaced or forked.
• Ramp-up. Applying the change is minutes for an application already on Statamic 4/5 — a constraint edit and a test run, well within a single engineer's afternoon. The genuine ramp-up is the Statamic 3 → 4/5 upgrade itself: unfamiliarity with Statamic's major-version migration guide, Antlers and fieldtype behavior changes, and addon compatibility review. Budget days per application for a straightforward site upgrade and weeks where heavy CP customization or custom addons exist, and staff it with whoever owns the CMS, not whoever owns dependency bumps.