Taskschedulerbundle Laravel Package

Product Decisions This Supports

• In-process recurring task scheduling: lets the product run periodic work (nightly reports, retention/cleanup, cache warmups, periodic data sync) from within the application rather than standing up separate cron orchestration or a hosted scheduler.
• Build vs. buy: a lightweight, low-cost dependency for scheduling needs that don't justify a dedicated scheduler service; reduces the surface area of infrastructure a small team has to own.
• Correctness of long-running jobs (0.13.0): the scheduler now resolves "current time" once before the first task executes, so long-running tasks no longer see time drift mid-run. This directly supports features where a task runs for minutes and subsequent scheduling decisions must stay consistent (e.g., a sync that spans a window boundary, batched backfills, chained cleanup jobs).
• Roadmap signal: if your roadmap includes long-running or overlapping scheduled work, treat >=0.13.0 as the minimum acceptable version; earlier 0.12.x releases carry the drift behavior.
• Delivery hygiene: the stricter code-style enforcement is internal housekeeping with no product-facing behavior change, but it lowers the odds of style-related merge friction and signals active maintenance — useful when justifying continued reliance on the package.

When to Consider This Package

Adopt when:

• You need straightforward recurring/periodic task execution inside an existing PHP application and don't want to operate external scheduling infrastructure.
• Your scheduled tasks can run long enough that time drift matters — 0.13.0 is the release that addresses this, so pin at or above it.
• You're comfortable pinning a pre-1.0 dependency and reviewing minor releases, since the public API may still shift.

Look elsewhere when:

• You need distributed or highly-available scheduling (multiple nodes, leader election, guaranteed single execution across a cluster).
• You require a stable 1.x+ API contract, long-term support commitments, or a formal deprecation policy — this is still a 0.x package.
• You're on Laravel and the framework's built-in scheduler already covers the use case; adding a second scheduling mechanism increases cognitive overhead for little gain.
• You need an operational UI, audit trail, or observability dashboard for scheduled jobs out of the box.
• You depend on precise wall-clock semantics across DST/boundary transitions and need documented guarantees — verify behavior against your requirements before committing.

How to Pitch It (Stakeholders)

For executives: This is a small, actively maintained dependency that lets us run recurring background work without buying or operating additional scheduling infrastructure. Release 0.13.0 delivers one meaningful correctness improvement — long-running scheduled tasks no longer drift in their notion of "current time" — plus internal code-quality tightening. There are no reported breaking changes, and the cost/risk of the upgrade is low. The main caveat is that the package is pre-1.0, so we should pin the version and budget a small amount of review effort per release.

For engineering: 0.13.0 changes when "now" is captured — evaluated once before the first task runs rather than repeatedly — which fixes time drift for long-running tasks and makes scheduling decisions deterministic within a run. The other change enforces a stricter code style; expect formatting-only diffs and no runtime impact. No deprecations or breaking changes are called out in the release notes. Recommendation: adopt at ^0.13.0 where long-running tasks exist, add a regression test covering a task that spans a scheduling boundary, and keep an eye on the 0.x changelog before each minor bump.