Statamic Factory Laravel Package

Product Decisions This Supports

• Platform upgrade timing (the primary decision). v1.5.1 is a compatibility patch: it bumps stillat/primitives to resolve Statamic 5 support. The decision this unlocks is concrete and dated — if your content stack runs Statamic 5, this is the version that lets the package stay in the dependency tree instead of being pinned, forked, or removed.
• Build vs. buy. A package that already maintains cross-version compatibility with a major CMS release is doing unglamorous, ongoing maintenance work you would otherwise absorb. Every future Statamic major (6, 7) becomes a "does the vendor ship a patch in our upgrade window?" question rather than a scoping exercise for your own engineers.
• Roadmap sequencing. Because the fix lands as a patch (1.5.1) rather than a minor or major, it signals the maintainer treats compatibility as corrective maintenance, not as new scope. That is a green light to schedule the Statamic 5 upgrade independently of this package's feature roadmap — the two are decoupled.
• Risk register entry. The transitive dependency on stillat/primitives is now a named upstream risk. Track it alongside Statamic itself: a break there propagates to you through this package, and your mitigation options are limited to pinning or patching.
• Ecosystem alignment / vendor diligence. This release is a data point for "is this package actively maintained against the current generation of its host framework?" One patch is weak evidence on its own; the pattern of releases around major Statamic drops is the signal worth watching.

Evidence caveat for the record: this assessment is based solely on the v1.5.1 release note. No usage data, issue history, or version cadence was available. The conclusions above are directional and should be re-confirmed before any irreversible decision (removal, fork, or a hard production dependency).

When to Consider This Package

Consider it when:

• You are on Statamic 5, or planning to move there within your current planning horizon — this release exists specifically to keep the package viable on that version.
• Your team is already invested in the stillat/* dependency family; adopting this keeps you on a coherent, mutually-tested set of packages rather than assembling one-off equivalents.
• You want compatibility maintenance outsourced. The value here is not the feature itself but that someone else tracked a CMS major and shipped the fix.
• The functionality it provides is adjacent to, not core to, your product — the classic case where buying/consuming beats building, because the maintenance cost is real but the differentiation is zero.

Look elsewhere when:

• You are on Statamic 4 or earlier and have no near-term upgrade path. This release targets 5; you would be running an untested-against-your-version combination, and the changelog gives you no reason to expect backported fixes.
• You require a committed support window or SLA. A single-line patch note with no stated deprecation policy, no LTS commitment, and no security disclosure process is not a foundation for a compliance-sensitive product.
• The package sits on a critical path where a transitive dependency bump can break production. The stillat/primitives coupling is the load-bearing risk; if you cannot tolerate it, absorb the function in-house.
• You would be its only meaningful consumer — at that point the maintenance relationship is inverted and you should own the code.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is a routine compatibility release for a supporting library, not a feature launch. Its significance is that it keeps one of our dependencies working on Statamic 5, which protects our upgrade timeline and avoids a bespoke engineering effort to replace or patch the package. Cost is effectively zero; the benefit is schedule protection. The only thing to note is a single upstream dependency we should keep an eye on, which I have logged as a low-severity risk.

To engineering — the working summary: v1.5.1 is a patch that bumps stillat/primitives for Statamic 5 compatibility. No API changes, no deprecations, no migration work. Practical guidance: safe to take on any branch already on Statamic 5; do not take it on Statamic 4 without verifying the transitive bump resolves, since the release note addresses 5 specifically. Treat stillat/primitives as a watched transitive dependency — if it breaks, we break, and our options are pin, patch, or replace.

Framing to avoid: do not present this as "the package is now secure / approved." One compatibility patch is not a maintenance guarantee. If pressed for a recommendation, the honest position is: keep it, adopt the patch where we are on Statamic 5, and revisit at the next Statamic major release — that is when we find out whether the maintainer's compatibility discipline is a pattern or a one-off.