Petrinet Laravel Package

Product Decisions This Supports

• Platform modernization / upgrade roadmap: 2.1.0 states PHP 8 support, so this package no longer blocks an application move off PHP 7.x. That removes a dependency-level blocker from the larger PHP 8 migration epic rather than forcing a package swap or an in-house replacement.
• Build vs buy: where the alternative is first-party code we would also have to carry across every future PHP upgrade, a package whose maintainers track upstream runtime releases lowers long-term maintenance cost.
• Risk and security posture: PHP 7.4 is end-of-life. A dependency receiving PHP 8 compatibility work is evidence of active maintenance, which feeds vendor-risk scoring and security review.
• Roadmap sequencing: this is a compatibility milestone, not a feature milestone. Don't put it in user-facing release notes; use it to close the "dependency compatibility" workstream on the PHP 8 upgrade.
• Open questions to resolve before committing: Does 2.1.0 cover PHP 8.0 only, or current 8.x (8.1–8.4)? Does it drop PHP 7 support, which would be breaking for any service still on 7.x? Does "support" mean "runs" or "covered by the CI matrix"? The answers determine whether this is a safe bump or a coordinated migration.

When to Consider This Package

Adopt or keep it when:

• The application is on, or moving to, PHP 8.x and this package is already a dependency — 2.1.0 removes it as a migration blocker.
• You want a dependency that responds to platform-level changes instead of pinning your application to an unsupported runtime.
• The functionality is non-differentiating (infrastructure/plumbing) and buying beats building.

Look elsewhere or hold when:

• You still run PHP 7.x in production with no migration date — a PHP 8-only release may be a breaking upgrade; check whether the 2.0.x line remains supported.
• You need a specific PHP 8 minor (e.g. 8.3 or 8.4) and the notes don't confirm it — "PHP 8 support" alone is not a version contract.
• The package is load-bearing, single-maintainer, and ships without a visible CI matrix — a one-line release note is thin evidence of ongoing quality.
• The underlying need is small enough that a few lines of first-party code avoids the dependency entirely.

How to Pitch It (Stakeholders)

Executives: "A dependency we rely on shipped PHP 8 compatibility. That keeps our runtime upgrade on schedule and removes one more reason we'd be stranded on an unsupported PHP version. No new cost, no feature change — just reduced platform risk."

Engineering: "Version 2.1.0 adds PHP 8 support. Before we bump, confirm three things: which PHP 8 minors are actually in the CI matrix, whether PHP 7 support was dropped (breaking for anything still on 7.4), and whether API changes are bundled in. Treat it as a routine dependency bump on the PHP 8 migration branch, not a feature upgrade — update the lockfile, run the suite on 8.x, and verify against the matrix before merging."