Scheduling Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for scheduling/queue logic. This is a narrow, domain-specific component (schedule/slot management, evidently within the Novo SGA service-desk ecosystem). Shipping as v2.3.0 with LTS alignment strengthens the "buy/adopt" side of the ledger versus building slot logic in-house.
• Platform lifecycle planning. The Symfony 7.1 → 7.4 LTS upgrade is the headline item: it moves the dependency onto a long-support track, which supports roadmap decisions about how long we can keep a PHP service on its current framework major.
• Customer-facing quality / support-cost reduction. The UTC-in-commands and unit-timezone-in-confirmation fix targets a class of bug that generates real support tickets ("my appointment shows the wrong time"). This supports decisions about multi-timezone or multi-region rollout — previously a risk area, now materially de-risked.
• Feature scope for back-office UX. "UX improvements and sync button" is end-user visible work in the admin/back-office surface. It's shippable value we get without custom development, and it's demoable to stakeholders as a delta from 2.2.0.
• Framework-fit decision (important caveat). Despite being framed as a Laravel/PHP package, the evidence points to a Symfony bundle (Symfony upgrade path, Symfony deprecation cleanup). For a Laravel stack this becomes a "buy-and-bridge" decision, not drop-in adoption — that reframes the integration cost estimate.
• Vendor/OSS health scoring. Dev tooling bumps (PHPStan 2, PHPUnit 11, PHPCS 4) plus deprecation cleanup are maintenance-hygiene signals that feed directly into a dependency risk score.

When to Consider This Package

Consider adopting when:

• You are on Symfony 6.4/7.x and need scheduling or queue-slot logic — this is the natural fit and the upgrade path is already validated by the maintainer.
• You are building in or adjacent to the Novo SGA service-desk/attendance domain, where the data model will already align.
• Long-term framework support matters to your release commitments (the 7.4 LTS move is the strongest argument here).
• Timezone correctness in confirmations is a known pain point for you.

Look elsewhere or proceed with caution when:

• Your stack is Laravel. There is no service provider, config publish, or Laravel integration surface in evidence. Budget for a bridge/adapter layer before committing.
• You need a framework-agnostic scheduler with no Symfony coupling.
• You require a formal backward-compatibility policy, security disclosure process, or SLA — none is evidenced in the release notes.
• Bus factor is a concern. PR numbers in the #4–#8 range alongside a reference to issue #455 suggest a very small maintainer cohort. Single-maintainer dependencies need an exit plan.
• You need mature documentation or i18n — the changelog is terse and release notes are the primary signal available.

Release-level read: 2.2.0 → 2.3.0 is a minor bump with no breaking changes or deprecations announced. This is a low-risk upgrade, not a migration event.

How to Pitch It (Stakeholders)

To executives: A small, actively maintained PHP scheduling component just shipped a maintenance release that keeps it on the current Symfony LTS and fixes a customer-visible timezone bug in appointment confirmations. Adoption cost is low if we're on Symfony and moderate if we're on Laravel, where we'd need a thin adapter. Recommendation: approve a short, timeboxed spike rather than a firm commitment — the release lowers technical risk but doesn't resolve the framework-fit question or the single-maintainer dependency.

To engineering: v2.3.0 upgrades Symfony 7.1 → 7.4 LTS, bumps dev tooling (PHPStan 2, PHPUnit 11, PHPCS 4), clears Symfony 7.4 deprecations, fixes UTC handling in commands and timezone display in confirmations, and adds back-office UX improvements plus a sync button. Nothing is flagged as breaking — treat it as a safe minor upgrade and validate in a branch. Two things to confirm before we invest: (1) this is a Symfony bundle, so scope the Laravel adapter work explicitly; (2) assess maintenance depth, since the contributor footprint looks narrow. If the spike passes, the LTS alignment gives us a multi-year support window to build on.