Statamic Graphql Alternate Locales Laravel Package

Product Decisions This Supports

• CMS upgrade planning (primary): v1.1.0's sole change is Statamic 6 support, which directly informs whether our Statamic upgrade can proceed without dropping this package. Treat this release as the compatibility gate for that roadmap item.
• Build vs. buy: If the capability this package provides is on our near-term roadmap, this release is evidence the maintainer is keeping pace with the platform. That lowers the cost/risk side of "buy" — but at 1.1.0 the package is still pre-2.0, so weigh it against in-house build only for non-differentiating functionality.
• Dependency hygiene / technical debt: Pinning to 1.1.0 lets us adopt Statamic 6 and retire any local shim or fork we built to bridge compatibility. Worth sizing that cleanup as a one-time engineering win.
• Use cases it serves: Statamic-backed content and marketing sites running on Laravel — editorial tooling, content modeling extensions, or delivery-layer features layered onto the CMS.
• What this release does not decide for us: it is not a feature release. No new end-user capability, no API surface expansion. It should not move roadmap priorities on its own; it removes a blocker rather than creating an opportunity.

Evidence caveat: this assessment is based on a single line of release notes. Package scope, license, maintainer count, and test coverage are unverified and should be confirmed before this feeds any build-vs-buy decision.

When to Consider This Package

Adopt when:

• You are on, or actively migrating to, Statamic 6 and need this capability — v1.1.0 is the minimum viable version for that platform.
• You want a Laravel-native addon (same framework, same deployment, same auth/permissions model) rather than a separate service to operate.
• The capability is adjacent to your product, not core to it — i.e., you can tolerate 1.x versioning and a small maintainer surface.
• You are already standardized on Statamic and want to avoid maintaining a bespoke integration.

Look elsewhere / defer when:

• You remain on Statamic 4 or 5 with no upgrade timeline — confirm backward compatibility before assuming this release is safe for you, since the notes only describe the forward path.
• The functionality is a load-bearing part of your product and you need stability guarantees, an SLA, or a second maintainer — a 1.1.0 addon with a single-line changelog does not yet demonstrate that.
• The requirement can be met with Statamic core or a first-party feature; adding a third-party addon for parity functionality increases upgrade surface for no gain.
• You are not on Statamic at all — nothing here is relevant, and a plain Laravel package should be evaluated on its own merits instead.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release, not a new capability. It keeps a dependency current with Statamic 6 so our CMS upgrade path stays open. Cost and risk are both low; the decision required is simply whether to schedule the Statamic 6 upgrade now or defer. It does not change product scope or commitments.

For engineering: v1.1.0 adds Statamic 6 compatibility. Before adopting: confirm our current Statamic version and whether the package still supports it, check the constraint in composer.json, and review test coverage and maintainer activity — a one-line changelog at 1.1.0 warrants a look at the repo's release cadence rather than a blind bump. Plan the upgrade as a scoped dependency change with a rollback pin, and flag any local workarounds we built for the older Statamic version as removable.