Screen Bundle Laravel Package

Product Decisions This Supports

• Roadmap confidence for scheduling-dependent features. Release 1.1.7 is a targeted bug fix for channel scheduling — the mechanism that determines when content plays on which screens. If screen/channel scheduling is on your roadmap (campaign windows, dayparting, playlist rotation, emergency overrides), this patch reduces the risk that a scheduling defect undermines a launch or demo.
• Build vs. buy for digital signage primitives. The package supplies domain building blocks (screens, channels, scheduling) rather than an end-to-end product. A PM can use it to avoid rebuilding scheduling logic from scratch and redirect engineering effort toward differentiation (CMS UX, analytics, integrations) instead of core signage plumbing.
• Maintenance-health signal for vendor/OSS dependency review. A same-scope patch release indicates the maintainers are actively triaging defects in the scheduling path. Useful input for dependency risk scoring and for deciding whether to standardize on the OS2Display ecosystem.
• Use cases to prioritize: internal communications screens, retail/queue displays, lobby and wayfinding signage, and any product where content must be time-boxed per channel. Channel scheduling correctness is table stakes for all of these, so this fix supports go/no-go decisions on scheduling-driven pilots.
• Release cadence planning. Because this is a patch-level fix with no feature surface change, it can be absorbed in a routine dependency bump rather than a dedicated sprint — useful when negotiating capacity with engineering.

When to Consider This Package

Consider it when:

• You are building digital signage or display-management capability on a PHP stack and need screen/channel scheduling as a domain concern rather than something you invent.
• You are already inside the OS2Display ecosystem, or are willing to accept its conventions (note: this is a Symfony bundle, not a Laravel-native package, so Laravel adoption implies integration work — bridging, service container differences, and possibly a separate runtime).
• You want open-source, self-hosted control over signage logic and are prepared to own operations, deployment, and upgrade testing.
• Scheduling correctness matters and you value an actively patched scheduling path over an unmaintained alternative.

Look elsewhere when:

• You need a managed/SaaS signage product with hardware, player apps, and support SLAs — this is a library, not a service.
• Your team is Laravel-first with no Symfony experience and no appetite for cross-framework integration; the total cost of ownership may exceed a native or headless-CMS-based alternative.
• You need rich scheduling semantics beyond channel-level windows (e.g., complex recurrence, audience segmentation, programmatic ad decisioning) — validate fit before committing.
• You cannot tolerate ecosystem coupling or require vendor-backed long-term support contracts.

Adoption criteria to satisfy first: a spike proving the bundle integrates with your framework and deployment model; a regression test covering your specific scheduling scenarios; and a documented upgrade path for patch releases like 1.1.7.

How to Pitch It (Stakeholders)

To executives: This is a low-risk maintenance release for an open-source digital signage component. It fixes a defect in channel scheduling — the logic that decides when content appears on which screen — which is precisely the capability our signage roadmap depends on. There are no breaking changes, no new features, and no migration cost; the impact is reduced operational risk and improved reliability of scheduled content. It also gives us evidence the project is actively maintained, which strengthens the case for standardizing on it rather than building scheduling ourselves.

To engineering: Version 1.1.7 is a patch containing a single merged fix for channel scheduling (PR #14). Treat it as a routine dependency bump: review the diff, run scheduling regression tests, and confirm no behavioral change to existing channel windows. Flag for the team that the package is a Symfony bundle, so Laravel integration requires deliberate bridging work; capture that effort in the spike estimate. No deprecations or API changes are signaled, so upgrade risk is minimal.