Reusable library and incompatible Django core changes

Django Internals ORM
1

We are developing a library and want to use CheckConstraint in our code. We intend to support all Django supported versions with a single codebase. Unfortunately, the depreciation and removal schedule make it tricky.

Django 6.0 will stop supporting CheckConstraint(check=...) in favor of CheckConstraint(condition=...) syntax introduced in Django 5.1. But there is still Django 4.2 LTS which does not support this syntax, which will be supported until April 2026 while Django 6.0 is scheduled to be released in December 2025. We’re testing with Django main branch, so we noticed this upcoming breakage quite early (and that’s the purpose of that testing).

I don’t really see a practical solution to this:

  • Develop and maintain Django version dependant code in models and migrations. Is this so rare use-case that every library should handle this on their own?
  • Drop support for Django < 5.1. Our Django LTS users might not get security fixes after that.

Maybe Django could make the compatibility interface removal schedule in sync with LTS releases to make such changes smoother?

1 Like
2

See the in development Django 6.0 release notes, on Third-party library support for older version of Django

Following the release of Django 6.0, we suggest that third-party app authors drop support for all versions of Django prior to 5.2.

That is you’re advised to drop support for Django 4.2 at that point. (Older versions of your package will continue to work for those last few months before Django 4.2 is EOL.)

3

I’m not sure I understand the dilemma here.

Even if you were to keep supporting 4.2 which is advised against as @carltongibson pointed out it should be relatively easy to write logic that either use self.check or self.condition based on django.VERSION?

By searching through your Github history I figured the problem you are facing is this one? I’ll comment over there on how this can be solved for the migration as well using a django.VERSION branch.

1 Like
4

Yes, that’s it (but I will most likely hit similar issues elsewhere as well). It can indeed be addressed by django.VERSION based conditions (what I find annoying), but it’s probably the best way we can do for now.

But I apparently skipped the top part of the Django 6.0 release notes, so I didn’t see the recommendation to drop support for LTS release while adding support for Django 6.0. Thanks, @carltongibson for pointing that out.