Statamic Hubspot Laravel Package

Product Decisions This Supports

• Platform lifecycle and upgrade planning. This release is primarily a compatibility milestone: Laravel 13 support, PHP 8.3 floor, Statamic 6.5 floor. For a PM, that's a signal to slot the package into your next framework-upgrade roadmap rather than treat it as a feature release. It answers "can we move to Laravel 13 without dropping our forms layer?" with a qualified yes.
• Build vs. buy for form handling. The package handles form configuration/serialization inside Statamic (FormConfig entries, serializable classes registered via Statamic's registerSerializableClasses API). That is undifferentiated plumbing — a strong argument for buying/adopting rather than building, provided your Statamic version is current enough.
• Security and compliance posture. The fix for deserialization under Laravel 13's hardened cache is a real reliability/security-adjacent item: hardened cache plus allowlisted serializable classes means form configs persist safely across cache layers. Worth flagging to security reviewers as a positive control, not just a bugfix.
• Risk scoping for the upgrade. The raised minimums (PHP 8.3, Statamic 6.5) are the actual decision input. They define a hard prerequisite chain: Laravel 13 → PHP 8.3 → Statamic 6.5 → this package v2.1.0. That's the dependency graph to hand to engineering for sizing.
• Roadmap sequencing. Because adoption forces PHP and Statamic upgrades, this becomes an anchor dependency that can gate other work. PM should treat it as a scheduled platform initiative with its own line item, not a routine dependency bump.

When to Consider This Package

Adopt when:

• You are on (or planning) Laravel 13, PHP 8.3+, and Statamic 6.5+ — the package's stated floor. Below any of those, v2.1.0 is not installable and you should stay on the prior line.
• You rely on Statamic-managed form configuration and need those configs to survive cache layers, queue workers, and serialization boundaries without silent failures.
• You want serialization handled through Statamic's sanctioned allowlist API rather than bespoke workarounds — i.e., you value upstream-aligned behavior over local patches.
• Your team lacks appetite to own form-config serialization internals; the maintenance surface here is small and vendor-owned.

Look elsewhere or defer when:

• You are pinned below PHP 8.3 or Statamic 6.5 for other reasons — this release offers you nothing and may block installs.
• Your forms are simple and fully static; a dedicated forms package may be overkill.
• You need guarantees this release note doesn't provide. There is no migration guide, no deprecation notice, and no deprecation path for older majors in the notes — if you're on v1.x or an earlier v2.x, confirm the upgrade story with the maintainers before committing.
• You require performance or scale evidence; none is present here, and this is a compatibility release, not a capability one.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release that keeps our forms layer compatible with the current Laravel and Statamic platforms and closes a cache-serialization defect. It doesn't add user-facing features; it prevents an upgrade from becoming a blocker. The tradeoff is a raised technology floor — PHP 8.3 and Statamic 6.5 — which we should plan for rather than absorb reactively.

For engineering: v2.1.0 adds Laravel 13 support and fixes FormConfig deserialization against Laravel 13's hardened cache by registering the allowlist through Statamic's registerSerializableClasses API — the correct, upstream-blessed approach. Minimums are now PHP 8.3 and Statamic 6.5. If we're below those, this is a no-op until we upgrade; if we're at or above, this is a low-risk adoption that removes a known caching failure mode.

Bottom line for the decision: low feature value, high hygiene value. Approve as part of the platform-upgrade track, not as standalone product work, and confirm the upgrade path from our current major before scheduling.