Statamic Buddy Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing. v2.0.0 drops Statamic 3 support, which makes this release the dependency-side trigger for any CMS upgrade work already on the roadmap. If a Statamic 3 → 4/5 migration is scheduled, this package's v2 line becomes adoptable immediately after; if no migration is scheduled, the decision is simply "pin ^1.x and revisit."
• Support matrix / tiering. For agencies or multi-tenant products, this defines which sites can take the v2 line (Statamic 4+) versus which stay frozen on v1.x (Statamic 3). That's a per-property decision, not a global one.
• Build vs buy. The package remains the cheaper path for its Statamic-integration surface than forking or reimplementing. A v2 major that tracks current Statamic majors is a positive signal that the maintainer intends to keep pace with the platform rather than let the addon rot.
• Dependency risk register. The single-line release note is itself a data point: version support boundaries are enforced via the composer constraint rather than documented migration guides. Budget verification time — read composer.json for the actual statamic/cms constraint before committing to an upgrade window.
• Roadmap confidence. A maintainer willing to cut a major for a platform-support drop (rather than carrying dead compatibility code) generally means fewer surprise breakages later. This supports keeping the dependency in the "healthy" bucket rather than the "watch for replacement" bucket.

When to Consider This Package

• Adopt v2 if you are already on Statamic 4 or 5, or your CMS upgrade is committed and funded. The breaking change is a compatibility-window narrowing, not an API redesign — for Statamic 4/5 consumers the upgrade cost is likely a composer constraint bump plus a regression pass on CMS-touching features.
• Stay on v1.x if you are on Statamic 3 with no funded upgrade. Do not let this release pull a CMS migration into a sprint; v1.x is the correct answer until the platform move is real.
• Verify before adopting either way: the release notes state what was removed but not the resulting minimum. Confirm the new statamic/cms constraint and whether any transitive Laravel/PHP floor moved with it — a Statamic major drop often rides alongside a PHP version floor change, which is the actual upgrade cost driver.
• Look elsewhere if you need a package with an explicit LTS or security-backport policy for older Statamic majors, if you're maintaining Statamic 3 sites indefinitely, or if this package is the only thing blocking a CMS upgrade — in that case the dependency is a coupling risk worth evaluating against alternatives.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release that narrows platform support to current Statamic versions. If we're already on Statamic 4 or newer, effort is low — a dependency bump and a focused regression pass. If we still have properties on Statamic 3, they stay on the previous major at no cost, and this release simply puts a date on a CMS upgrade we already knew about. No new capability, no new spend, and a positive signal that the maintainer keeps the package aligned with the platform.

For engineering: v2.0.0's only stated breaking change is removal of Statamic 3 support. No feature or API changes are claimed, but the release note is one line, so treat the composer constraint as the source of truth — check the minimum statamic/cms and PHP versions before planning the bump. Recommend: pin v1.x on any Statamic 3 branch, upgrade Statamic first where needed, then move to v2 in a single follow-up change so the two breaking surfaces don't get debugged together.