v2023.5.0b1

[cunla]

New release v2023.5.0-beta1 coming soon.

There are two breaking changes:

• No more threaded scheduler (I heard you :) ).
• Remove django-rq dependency.

This enables significantly better django-admin views and integration between the redis-model and the django-model.

• admin views revamped: For each job the executions that are in redis (while their TTL hasn't passed).
• documentation improved: now it includes mermaidjs sequence diagrams, etc.
• import/export management commands support to enable easy upgrade/downgrade.

Overall, the roadmap:

• Remove the rq dependency as well and implement the redis-model in a simpler format.
• Simplify the redis-queues by having all queues in the same redis-database.

I would like to have beta testers for v2023.5.0b1 - please let me know if you can participate.

[gabriels1234]

Hi! Sorry for not finding this earlier. (I did not have the time as well).

Questions:

1. isn't it better to keep current urls structure "/admin/scheduler/..."? (= no extra step in installation + easier uninstall) (or perhaps fallback when /scheduler is not present?)

2. Regarding the roadmap, I think the rq project is pretty robust and has already hundreds of contributors, and is kept freshly updated. Any bug in the code here has a "single-point-of-failure". This could mean people not becoming interested in this project because they have minimum standards.
   My next thought was: Let's make it so they can "coexist". But then you would have to keep up with their breaking changes.

3. My next idea would be: "make it opt-in, let people decide and switch back and forth until they are ready for it". Make django_rq optional (it would used it if installed, or at lease it won't conflict), and make rq optional (you can have your own replacement as the default, but allow for it to be overrridden)

I just don't want these decisions to turn away people because of breaking changes (or pin to an old version to avoid issues, and miss all the good features you are introducing).

Just Consider this: the project has 4200/downloads/month (so there are people building on top of django-rq-scheduler) but they are not being present in the conversation. Imagine what would happen when suddenly their projects start breaking...

Thank you!!!

[cunla]

Hi! Sorry for not finding this earlier. (I did not have the time as well).

No problem. I am happy to hear your feedback any time.

1. isn't it better to keep current urls structure "/admin/scheduler/..."? (= no extra step in installation + easier uninstall) (or perhaps fallback when /scheduler is not present?)

I assume you mean migrating the django-rq URLs to scheduler (otherwise please specify...).
There are multiple features added to the different views. The implementation is completely different than the django-rq. I maintained similar template to ensure an easy transition, but you can notice there are more information and more linking within the views.

2. Regarding the roadmap, I think the rq project is pretty robust and has already hundreds of contributors, and is kept freshly updated. Any bug in the code here has a "single-point-of-failure". This could mean people not becoming interested in this project because they have minimum standards.

I am not a fan of how RQ is maintained. Having 100s of contributors does not mean well-maintained. I approached the current maintainers but did not get a response.

My next thought was: Let's make it so they can "coexist". But then you would have to keep up with their breaking changes.

Currently, since django-rq-scheduler and django-rq are both based on RQ => They can coexist and be transparent to each other.
Once django-rq-scheduler becomes independent of RQ, they could co-exist, however, they would be mutually exclusive (RQ queue would not be scheduler queue and vice versa).

3. My next idea would be: "make it opt-in, let people decide and switch back and forth until they are ready for it". Make django_rq optional (it would used it if installed, or at lease it won't conflict), and make rq optional (you can have your own replacement as the default, but allow for it to be overridden)

RQ will be necessary for a while, django-rq is already optional.

I just don't want these decisions to turn away people because of breaking changes (or pin to an old version to avoid issues, and miss all the good features you are introducing).

Just Consider this: the project has 4200/downloads/month (so there are people building on top of django-rq-scheduler) but they are not being present in the conversation. Imagine what would happen when suddenly their projects start breaking...

I fully understand and would want more people in the conversation. I appreciate that you are here!
The purpose is to enable users to use it easy as possible to use (as the original purpose of RQ: low barrier to entry).

I am balancing between the easiness of upgrading and the easiness of installing for new users. Working with the assumption that upgraders are more experienced, the preference is a little tilted toward making things easier for new users.

• With the current changes, new users do not need to install django-rq, look at two separate documentations, etc. while upgraders are nearly not impacted (just adding a new set of URLs).
• With the future roadmap changes, new users would have an end-to-end solution without needing to know about django-rq or rq. Upgraders would benefit from a one-stop-shop (which is also, I agree, a single point of failure).