Remove upper bound on Django version

[realsuayip]

Why?

Adding upper bound on Django makes it hard to test the library in new Django versions (even if there is no official support).

Currently i'm trying to use Django 6.0 alpha but django-celery-beat won't let me. This is not productive because:

a) users won't be able test the library against new Django versions, making them unable to report potential bugs beforehand
b) in case a new django version is found compatible, users still need to update django-celery-beat (which they might not want to do)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.18%. Comparing base (d9b84c3) to head (c6b936c).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #971   +/-   ##
=======================================
  Coverage   88.18%   88.18%           
=======================================
  Files          32       32           
  Lines        1007     1007           
  Branches      105      105           
=======================================
  Hits          888      888           
  Misses        101      101           
  Partials       18       18           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cclauss]

A long discussion of why we have been setting an upper limit when we have lots of user issues:

• Remove Strict Upper Version Limit for Django #755

[realsuayip]

A long discussion of why we have been setting an upper limit when we have lots of user issues:

• Remove Strict Upper Version Limit for Django #755

Thanks for the reference. I have now read the majority of the discussion and still not convinced that strict upper pinning is required. And the community seems to support this too.

Of course, I'm not asking people to create a library that potentially supports all future Django versions. This is a separate concern aka 'confirmed support'

When users upgrade their Django and break django-celery-beat, they can create issues to ask for 'official support' that's fine. But withholding them from upgrading is not useful at all (see my points above)

What if somebody breaks their setup without realizing / haphazardly upgrading?

The answer is that's their responsibility; this is why lockfiles exist. People should not upgrade Django without checking confirmed support from Django packages.

[cclauss]

Help is needed on the 100+ open issues.

• https://github.com/celery/django-celery-beat/issues

[auvipy]

this is the saner option

[auvipy]

But withholding them from upgrading is not useful at all (see my points above)

no one is withholding anyone. anyone can maintain their separate forks to meet and fit their needs

[realsuayip]

anyone can maintain their separate forks to meet and fit their needs

Yes, but how is that useful for django-celery-beat though? Do people really have to maintain a fork just to test django-celery-beat with newer Django versions?

I'm not asking for a super-specific feature that merits it own fork. And I'm not asking for unrealistic support/maintenance either.

[auvipy]

anyone can maintain their separate forks to meet and fit their needs

Yes, but how is that useful for django-celery-beat though? Do people really have to maintain a fork just to test django-celery-beat with newer Django versions?

I'm not asking for a super-specific feature that merits it own fork. And I'm not asking for unrealistic support/maintenance either.

every project has its own maintenance support policy and time constraint. if that does‘t suite some ones need and they are in a hurray, they can maintain their own fork until a new release come. it is kind of the norm.