Compatibility List

[Benny M]

Hi all,

I have a project that’s doing a rather sizable jump from 1.11.29 to 3.1.
I’m aware of the internal gotchas (enforced on_delete, settings syntax, etc) - but I was curious if anyone knows of a package compatibility list exists?
Something like caniuse but for django-focused packages. Right now I’m just going through the changelogs of the packages used in the project and making an educated guess.

If one doesn’t exist (could be a fun and useful project?) please feel free to mention any gotchas you’ve found.

Thanks!
Benny

[Mike Dewhirst]

On 31/12/2020 2:16 pm, Benny M wrote:
> Hi all,
>
> I have a project that’s doing a rather sizable jump from 1.11.29 to 3.1.
> I’m aware of the internal gotchas (enforced on_delete, settings syntax, etc) - but I was curious if anyone knows of a package compatibility list exists?
> Something like caniuse but for django-focused packages. Right now I’m just going through the changelogs of the packages used in the project and making an educated guess.

No need to read the changelogs unless something goes badly wrong. Read
the release notes instead.

https://docs.djangoproject.com/en/3.1/releases/

They cascade down the page all the way to 1.11

Here is the recommended mechanism ...

https://docs.djangoproject.com/en/3.1/howto/upgrade-version/

Effectively 2.2 is as far as you need to go for the time being because
it is an LTS release. Might make a convenient initial goal. Should be
pain-free.

Cheers

Mike

>
> If one doesn’t exist (could be a fun and useful project?) please feel free to mention any gotchas you’ve found.
>
> Thanks!
> Benny
>

--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Just
ask and I'll send it to you. Your email software can handle signing.

[Benny M]

Thanks for your response, Mike.
I was using “changelog” and “release notes” interchangeably; sorry for the confusion.

My question is more about packages that extend Django’s capabilities (i.e. django_csp, django_rq, etc.) as opposed to Django itself.

Thankfully Django has great release notes, so catching up there isn’t a problem. However, what would be good way to audit third-party dependencies to find out which ones need to be updated to work with 3.1, or which haven’t caught up?

Benny

[Benny M]

P.S.

>
> Effectively 2.2 is as far as you need to go for the time being because it is an LTS release. Might make a convenient initial goal. Should be pain-free.
>

Unfortunately that’s not an option.

[Mike Dewhirst]

If it was my project I would migrate it one increment at a time. I went
from 1.11 to 2.2 in one step but had to go back and review the release
notes here and there to resolve a tiny number of issues which were in
fact well flagged. It might have been easier to do the intermediate
upgrades.

Having loads of unit tests is probably the most important thing. Vital
if it is running on Python 2.7.

Adjusting from Python 2.7 in 1.11 to Python 3.x in 1.11 was also
important. I had it running on 3.6 and 2.7 before moving forward to 2.2

As for the packages, if they are currently supported I'm sure they will
be up-to-date.

YMMV

Mike