Event Laravel Package

Product Decisions This Supports

• Roadmap timing, not roadmap content. 8.0.0 is explicitly a packaging-driven major with no public API change. There is no new capability to schedule, demo, or market. Do not let a major version bump create a false signal that a feature investment is available.
• Platform/runtime decision (the only real PM decision here). Minimum PHP moves to 8.3. That is an infrastructure commitment: hosting/base images, CI runners, static analysis, and any co-deployed service on the same runtime. Treat this as a platform upgrade ticket, not a library upgrade ticket.
• Build vs. buy / dependency strategy. The coordinated jbzoo/* → ^8.0 bump is an ecosystem-alignment signal. If we consume more than one package from this family, the value proposition is coherence: upgrades land together, constraint conflicts are minimized. If we consume exactly one, we are paying the full ecosystem-major cost for a single library.
• Support-lifecycle planning. CI covers 8.3 / 8.4 / 8.5, which is a credible signal of active maintenance across current PHP lines — useful input to our security-patch and upgrade-window planning.
• Use-case fit is unchanged. The feature set we evaluated before this release is exactly the feature set we get now. Decisions about whether the package solves our problem should be made on that basis, not on the version number.

When to Consider This Package

Adopt when:

• We are already on, or will be on, PHP 8.3+ within the same window as the upgrade.
• We use, or plan to use, multiple jbzoo/* packages — the lockstep ^8.0 requirement means partial upgrades will produce Composer constraint conflicts. Upgrade the family together or not at all.
• The package is a supporting utility layer, not core domain logic, so a coordinated major cadence is tolerable.
• We want a dependency whose maintenance is demonstrably alive (multi-version CI) and whose changes are packaged rather than API-churning.

Look elsewhere when:

• We must support PHP 8.1/8.2 for contractual, customer-environment, or long-term-support reasons. This release hard-blocks that.
• We need an LTS-style stability guarantee or a documented deprecation policy tied to a support window rather than ecosystem coordination.
• We need Laravel-idiomatic integration (service providers, facades, framework-native config publishing) rather than standalone PHP utilities.
• Our dependency freeze windows conflict with an ecosystem-wide major cadence we do not control.

How to Pitch It (Stakeholders)

To executives: This is a low-drama, low-cost upgrade with no new features and no API changes. The only material ask is a PHP 8.3 runtime baseline across our environments. Risk is dependency-resolution churn during the upgrade, not code rewrite. Expect engineering days, not engineering weeks — and no user-visible change to communicate.

To engineering: Plan a single coordinated bump of all jbzoo/* constraints to ^8.0; upgrading one package in isolation will fail resolution. Confirm PHP 8.3 is available in CI, local tooling, and production images before merging. Run the full suite and static analysis against 8.3+; the changelog asserts no public API change, so failures should surface as environment or transitive-dependency issues rather than application code errors.

Caveat to state openly: the release note is thin — a version bump and a CI matrix. Before committing, confirm per-package changelogs and transitive requirements, since "no public API change" is an assertion, not a verified audit.