[Question] Future of SchedulerBundle

[ToshY]

Hey @Guikingone 👋

I've been using the SchedulerBundle for a couple of years now for my hobby project and I'm still very satisfied with it. Recently however, I have come across a relatively new component that Symfony introduced as "Scheduler" (added around SF 6.3).

While I personally like the approach the current bundle has regarding creating schedules with YAML config (and having dedicated console commands for it), I am inclined to migrate to the Symfony alternative, mostly because it is more actively maintained as a Symfony component.

My questions are as follows:

1. What are the key differences between SchedulerBundle and Symfony's Scheduler? ¹ What are the advantages of SchedulerBundle vs Scheduler (or vice versa)?
2. Would you suggest (new) users that are looking for a scheduler to use in their Symfony projects, to use SchedulerBundle or Scheduler?
3. Do you intend to further keep maintaining the SchedulerBundle, or would you suggest existing users to migrate tot Symfony's Scheduler as well (eventually)?

Thanks in advance.

Footnotes

1. I've looked at the original PR for the Scheduler component and your comments regarding you having a different vision on how a scheduler should work, but as I do not have to much knowledge on the subject, I don't know what to make of it 😅 Maybe explaining some of the key differences in simple terms between the two would help. ↩

[Guikingone]

Hi @ToshY 👋🏻

Sorry for the delay (saw you PR, was off last week, I'll handle it this weekend).

Hard question that you're asking here 😄

In short terms:

• SchedulerBundle: A naive implementation of the Linux scheduling mechanism in Symfony based around configuration (even if attributes can be added)
• Scheduler component: A wrapper around Messenger to handle repetitive tasks while taking benefit from the Symfony ecosystem

---

• SchedulerBundle is "my approach" when it comes to handling tasks in Symfony while staying "as close as possible" to the Linux implementation (either in the list, main scheduler implementation, etc), it does not reinvent the wheel around "infrastructure" (PHP is not built to be a long-running task worker) and allows you to configure tasks while storing them.

• Scheduler is a wrapper, it's not a "fully isolated" tasks handling system, you're relying on the Messenger component while being tied to its current API (for most users, it's fine, for others, depending on a component built for queues is not a good idea), it's the "Symfony way" of handling this kind of needs.

I have a strong opinion of the way Scheduler should work and as explained in the PR, I'm not convinced by the dependency on Messenger (I discussed with Fabpot about this, we have opposed visions on those aspects, it's fine) for performances issues, end-user experience and more.

For new users, if they don't have "advanced" use-cases that requires to "act like Linux", Scheduler is fine, it scale well and you're benefiting from the Symfony ecosystem.

For others users, if SchedulerBundle is fine for you, good, there's no new features for now (as I'm contributing mostly to Symfony AI recently) but I have plans about merging PRs and pushing new versions, if you prefer the Symfony approach and your project can handle the migration, Scheduler is a good alternative if you're okay with the dependency and the "internal API".

At the end of the day, I can't really recommend one solution or the other, both works differently but try to solve the same issue, people are free to explore both and pick the one that solve their problems while not being "a pain" for them 🙂