Statamic Bearhub Laravel Package

Product Decisions This Supports

• Build vs. buy for Statamic-adjacent functionality. This package sits in the Laravel ecosystem alongside Statamic, so the primary decision it informs is whether to extend an existing Laravel/Statamic install with an off-the-shelf package versus maintaining in-house glue code. The v1.1.2 dependency loosening directly improves the buy side of that equation: a narrower Statamic constraint is one of the most common reasons teams end up forking or reimplementing a package, and that pressure has now been reduced.
• Upgrade and platform-migration roadmap. Because the package no longer pins a tight Statamic version, it can be carried across a Statamic major/minor upgrade rather than treated as a blocker. This affects sequencing: teams can schedule the Statamic upgrade and keep this package in place, instead of budgeting a replacement or fork as part of the migration.
• Version-support policy for the product. If we ship anything that depends on this package, "loosen the upstream constraint" is a concrete precedent for how we treat transitive framework/CMS dependencies — prefer permissive constraints with a tested floor and ceiling over exact pins, so downstream consumers aren't forced into lockstep upgrades.
• Feature scope and use cases. The package is a supporting integration layer, not a product differentiator. It belongs in the "enabling infrastructure" bucket of the roadmap: it unblocks Statamic-based delivery work but should not itself anchor a feature commitment or a customer-facing promise.
• Risk register / maintenance posture. The release is maintenance-shaped (dependency relaxation plus routine package updates) rather than feature-driven. That is a signal the maintainer is actively tracking upstream compatibility, which is a positive input for a "keep vs. replace" review at the next planning cycle.

When to Consider This Package

Consider it when:

• We are already running Laravel with Statamic, or are committed to Statamic for the foreseeable roadmap, and need functionality this package provides rather than something we'd have to build and own.
• Our Statamic version is one the loosened constraint now admits — the v1.1.2 change is only valuable to us if it actually widens the set of versions we can run. Verify the concrete constraint range against our pinned Statamic version before treating this release as an unblock.
• We want to avoid owning a small, well-bounded integration ourselves. The total cost of ownership for thin glue code is easy to underestimate once upgrade churn is included.
• We need to stay on a supported Statamic release line without forking. Prior to this release, a tight constraint would have made forking the likely outcome.

Look elsewhere when:

• The Statamic dependency — however loose — is still a constraint we cannot accept, for example if the roadmap includes leaving Statamic, or if we need to run a Statamic version outside the newly declared range. "Loosened" is not "removed."
• The package's surface area overlaps with first-party Statamic or Laravel features we already rely on; adding a third-party layer for parity functionality increases upgrade surface for no gain.
• Our product is not Statamic-based at all. The dependency link is the defining characteristic here, and the v1.1.2 change reinforces rather than reduces that coupling.
• We require a stable, feature-frozen dependency for a long-term-support release. A patch release consisting of dependency changes is a reminder that the package's compatibility envelope moves with upstream, and we should confirm our lockfile and CI matrix actually exercise the versions we claim to support.

Caveat worth stating plainly: v1.1.2 is a patch release with a two-line changelog. It warrants a compatibility re-check and a lockfile bump, not a re-evaluation of the package's role in the roadmap. Treat the "updated packages" line as a prompt to run our own dependency and security scan rather than as evidence of hardening.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, low-risk dependency update to a package that supports our Laravel/Statamic work. The substantive change is that the package no longer locks us to a narrow Statamic version, which removes a known upgrade blocker and reduces the chance we'd have to pay to maintain a private fork. It does not add product capability, does not change our commitments to customers, and does not require a roadmap adjustment. Recommendation: adopt the update, confirm our current Statamic version falls inside the new supported range, and keep the package on standard maintenance rather than treating it as a strategic component.

For engineering — the short version: v1.1.2 relaxes the Statamic version constraint and refreshes transitive packages. That is a compatibility broadening, not a functional change, so the review work is: (1) read the new constraint and confirm our pinned Statamic version is inside it; (2) run the test suite and a staging deploy against that version, since a loosened constraint can silently permit combinations the maintainer has not tested; (3) re-run dependency and security scanning on the refreshed tree; (4) update our own composer constraint to match and drop any local patch or fork we were carrying to work around the old pin. If we were previously blocked from a Statamic upgrade by this package, that blocker is now cleared and the upgrade can be rescheduled — that is the only decision this release actually changes.