Statamic Uuid Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing (Statamic v6). v2.4.0 is a compatibility release that adds Statamic v6 support. If the Statamic v6 upgrade is on the roadmap, this addon is no longer a blocker — but it also effectively sets a floor: v2.4.0+ is the version to pin if v6 is in scope.
• Build vs. buy for identifier infrastructure. The capability (stable, generated UUIDs on content) is small but easy to get subtly wrong — backfilling existing entries, handling imports, keeping IDs stable across environments. A dedicated addon is usually cheaper than owning that logic, though the maintenance risk is concentrated in a single maintainer.
• Integration and data-contract decisions. Stable UUIDs decouple external systems (PIM/CRM/analytics/feed consumers, mobile apps, search indexes) from Statamic's internal IDs and URL slugs. This is the deciding factor when scoping any content-syndication or headless work, since slugs change and internal IDs are environment-specific.
• Content portability and migration. UUIDs make multi-environment promotion, content sync between staging/production, and future CMS migrations tractable. Relevant whenever "what if we move off Statamic" appears in planning.
• Not a feature release. There are no new capabilities, deprecations, or breaking changes for existing users in this version — treat it as a maintenance/compatibility update, not a reason to re-evaluate the product fit.

When to Consider This Package

Adopt when:

• You run Statamic and need durable identifiers for entries/content that survive slug changes, re-imports, and environment promotion.
• You are planning or actively executing a Statamic v6 upgrade and need addon compatibility confirmed.
• Downstream systems (APIs, feeds, warehouses, third-party integrations) already key off identifiers and you want them generated at authoring time rather than derived.
• You want this as configuration rather than custom application code.

Look elsewhere or defer when:

• You are on plain Laravel without Statamic — use native model UUID traits/ULIDs; this addon adds no value there.
• You only need identifiers at the database layer with no editorial/CMS workflow involved.
• You are not planning a Statamic v6 move and are already stable on v2.3.0 — there is no functional gain here.
• Maintenance risk tolerance is low. This is a small, single-maintainer addon (one contributor on this release). Before depending on it for a business-critical data contract, confirm issue responsiveness and test coverage, and have a fallback: the underlying logic is simple enough to vendor or reimplement if the package stalls. Also verify the v6 compatibility claim against your actual Statamic v6 version in staging — a compatibility bump is not the same as a v6 feature-parity guarantee.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk maintenance update to a small addon that gives our Statamic content permanent, portable identifiers — the thing that keeps integrations and reporting stable when URLs or internal IDs change. The headline is de-risking: the addon is now compatible with Statamic v6, so our planned platform upgrade is not blocked by it. No new spend, no migration work, no behavior change for current users. We should pin v2.4.0+ and confirm compatibility in staging as part of the upgrade checklist.

To engineering: v2.4.0 is a single change — Statamic v6 support. Nothing to refactor, no breaking changes for v5 consumers. Pin ^2.4.0 if you're moving to Statamic v6; stay put if you're not. Caveat to note in the upgrade ticket: it's a thin, one-maintainer package, so validate it against our target v6 version in staging and keep in mind that vendoring the UUID generation is a realistic fallback if maintenance lapses. Recommend we confirm before treating it as load-bearing for any external data contract.