Statamic Graphql Events Laravel Package

Product Decisions This Supports

• Build vs. buy (composer vs. in-house): The only signal in v0.3.1 is a bugfix on a pre-1.0 package. That's a maintenance signal — the maintainer is responsive — not a capability signal. Treat it as evidence for vendor health, not for feature fit.
• Roadmap timing: With no 0.x → 1.0 movement and no deprecations, there is nothing here that unblocks or blocks a roadmap item. Do not schedule work against this release; keep any dependency on it behind a version constraint (^0.3) and re-evaluate on a minor bump.
• Technical debt / upgrade budget: Patch-only releases on a 0.x line are cheap to absorb, so adoption cost this cycle is near zero. The real budget question is the eventual 1.0 cut, which for a 0.x package is where breaking changes are permitted to land. Flag that as an unscheduled risk, not a current one.
• Risk posture for a production dependency: A single-line "Bugfix" changelog tells you the fix happened but not what broke, what it affected, or whether consumers need to act. That's a documentation/process gap worth weighing if this package is (or would become) load-bearing.
• Portfolio triage: If this package is one of several candidates for the same job, v0.3.1 gives no reason to promote it or demote it. It stays where it is in the evaluation queue until a release ships something you can evaluate on merit.

When to Consider This Package

Consider it when:

• The problem it solves is adjacent to, not core to, your product — a supporting concern (integration glue, formatting, admin tooling, an internal convenience layer) rather than a differentiator you'd want to own.
• You can pin it (^0.3) and absorb a future 1.0 bump without coordinated cross-team work.
• The bugfix cadence suggests an actively maintained project, and you have the appetite to read the source or the diff — because the changelog won't tell you what changed.
• It's a spike or internal tool where reversibility is high and the exit cost of ripping it out is a day, not a quarter.

Look elsewhere when:

• You need an LTS or long-term support commitment. Pre-1.0 means the API is explicitly not frozen; a patch release today can be a breaking change at the next minor.
• The package would sit on a critical path (payments, auth, data integrity) where you need documented guarantees, a security disclosure process, and a changelog you can audit. "Bugfix" alone is insufficient due diligence for that tier.
• Your team's Laravel version is pinned and you need verified compatibility matrices rather than "it's a Laravel package."
• A first-party Laravel facility or a well-established alternative covers the same ground. For supporting concerns, ecosystem maturity usually beats novelty.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, actively maintained open-source Laravel component currently at v0.3.1. The release we just reviewed is a bugfix only — no new capability, no breaking change, no action required. We are not recommending it for anything on a critical path. Where it's a good fit is peripheral tooling, where the cost of adoption is low and the cost of removal is low. The one thing to watch is that the project hasn't reached a stable 1.0, which means a future upgrade may require engineering time; we'd size that when it happens rather than pre-allocate budget now.

To engineering (summary): Patch release, bugfix only, no deprecations, no API surface change that we can verify from the notes. Pin to ^0.3 and let the lockfile do its job. Two asks: (1) if we adopt, whoever integrates it reads the actual diff of this fix rather than trusting the changelog — the notes are too thin to be a substitute; (2) treat the eventual 1.0 as the real planning event, since that's where 0.x semantics allow breaking changes. If anyone is proposing this for a critical-path dependency, that's a separate conversation and this release doesn't answer the questions that conversation needs answered.