Swoole Bundle Scheduler Laravel Package

Product Decisions This Supports

• In-process scheduling vs. a scheduler fleet. If the app already runs on a long-lived Swoole server, this package replaces a set of cron entries / Kubernetes CronJobs / a dedicated scheduler service with timers inside the application process. The decision it unlocks is "can we delete a moving part from our infra?" — measurable in deploy artifacts removed and on-call surface reduced.
• Build vs. buy for periodic work. For a handful of recurring jobs (cache warmup, metrics flush, housekeeping, periodic sync), adopting a small package beats building an internal scheduler or standing up Airflow/Celery-style infrastructure. Useful input when scoping "do we need a real scheduler service?" — answer is often "not yet."
• Consolidation roadmap item. Supports a roadmap line like "reduce scheduled-job infrastructure to one runtime" — but with a caveat the team must accept: jobs share fate with the app process, so no ticks during deploys, restarts, or crashes.
• Risk/upgrade planning. The package is pre-1.0. Under semver, a 0.1.x → 0.2.0 bump is a permitted breaking-change window. This alone should not change a roadmap decision, but it does generate a concrete task: pin the version, read the v0.1.1...v0.2.0 diff, and rehearse the upgrade before wider adoption.
• What v0.2.0 does not support. The release ships no itemized changes, migration notes, or deprecation notices — only a diff link. So it provides no new evidence for or against adoption; it is a maintenance signal, not a feature signal.

When to Consider This Package

Pilot it when:

• The application already runs on Swoole (or the Symfony Swoole bundle family) — marginal cost of adoption is low and scheduling becomes a first-class, code-reviewed concern rather than an ops artifact.
• Jobs are short, idempotent, and tolerant of a missed tick: cache invalidation, metrics flushing, housekeeping, periodic sync, digest fan-out.
• The team is small and deliberately avoiding a second scheduler service to operate and monitor.
• You can pin a tag and absorb occasional 0.x breaking changes inside a normal maintenance window.

Look elsewhere when:

• You need durable at-least-once delivery, retries, backoff, dead-letter handling, job history, or an operator UI. Use Laravel queues + Horizon, Symfony Messenger, or a managed scheduler.
• Jobs are long-running or CPU-bound and would starve the event loop — this is the classic failure mode for in-process scheduling.
• You run PHP-FPM/nginx. There is no persistent process to schedule inside; use cron or a queue worker.
• Jobs carry SLAs. Co-locating the schedule with app availability means deploys and crashes drop ticks.
• You require a 1.0+ dependency with a stated support policy and security-response posture. This is a small-maintainer 0.x package; assess bus factor explicitly.
• Ecosystem fit must be verified. The package naming points at the Symfony Swoole bundle lineage, not a first-class Laravel integration. If your stack is Laravel-first, benchmark against the framework's built-in scheduler before adding a dependency at all.

How to Pitch It (Stakeholders)

Executives: This is a small, low-cost option to remove a category of infrastructure — the separate cron/scheduler fleet — for applications that already run on a long-lived PHP server. It is pre-1.0 and maintained by a small team, so the ask is a time-boxed pilot on non-critical jobs with a pinned version and a documented exit path, not a platform commitment. The v0.2.0 release documents no new capability and no migration guidance, so it does not change the business case; it simply confirms that upgrades will need a rehearsal step.

Engineering: The value is co-locating periodic work with the Swoole event loop — fewer deploy artifacts, one process to observe and instrument. The cost is coupling: schedule availability now equals app availability, and you get no retry, backoff, or idempotency guarantees beyond what you write yourself. Treat v0.2.0 as an unvetted upgrade: diff v0.1.1...v0.2.0, check for signature and configuration changes in the README/CHANGELOG, and run the pilot suite against a pinned tag before merging — a 0.x minor bump is allowed to break. Keep the integration behind a thin adapter interface so swapping to a queue or an external scheduler later is a config change, not a rewrite.