Closed cunla closed 2 years ago
@cunla I reviewed your commits. Some of the refactoring is definitely on point and so is your project standards. However I would prefer that we maintain a single code base for multiple Django versions and I think it can be managed. Do let me know if re-merging the code makes sense for you? Our tech team will have (allotted) bandwidth to keep looking into this regularly so can support on a more than volunteer basis. Cheers
Hi @eskhool, thanks for getting in touch.
I would like to be the maintainer for this package and created a request in pypi to claim the package name. We are a group of professional python developers who will maintain it - you are naturally welcome to use the package and merge the code to yours, or alternatively participate in maintaining the new repository (open issues, create PRs, etc.).
Hi @cunla, it looks by the name of your repo that you intend to keep it for Django 4 onwards only? If thats the case, then I guess we will probably cherry pick and adapt merge your changes if we can to keep this package working with Django 3.2
@eskhool, I do agree with your stance on having the project support the Django 3.2 LTS release. I don't have project owner access to PyPi myself and am unsure what to do. We're using my own fork at our company and the fragmentation of this project is obviously concerning to me.
I'll add django 3.2 support today
I'll add django 3.2 support today
Great, this evening (currently on vacation) I'll have a look through the updates you've made on your fork and see if I've got any comments / input.
Find here PR for django3.2 support.
Version published on pypi: https://pypi.org/project/django-rqscheduler4/
Currently the name is still django-rqscheduler4. I have claimed the django-rq-scheduler
name on pypi and hopefully soon they will approve it.
ugettext_lazy
=>gettext_lazy
django.conf.urls.url
=>django.url.re_path
As described here