Page Comparison

...

Under the effort of Django 4.2 Upgrade, complete all of the following steps to complete the upgrade.

• Add Fix Django 4.0 and Django 4.1 Deprecation Warnings

  • When running tests against Django 3.2

  test support

  • , there would be Django 4.* Deprecation warnings in the test logs.

  • You can use third party django-upgrade tool to fix most of the deprecation warnings and refactor your code automatically.

  • If there are still any deprecation warnings left, you can go through the edx-platform deprecation issues to identify any specific warning and the method to resolve it.

• Upgrade to Django 4.2 in tox & Github action workflow

  • This step can be done by using modernisers created by the tech-arbi-bom team.

  • You can simply run the provided modernisers after installing the repo-tools package within a virtual env and it’ll make all the needed changes for Django 4.2 support in both tox.ini and ci.yml files.

  Remove any versions of Python earlier than 3.8

  • If there are any Python<3.8 and Django<4.2versions present in the tox.ini or ci.yml which are not updated by the moderniser script, those should be removed.

• Run tests with Django 4.2

  • Run and verify all tests are passing in the CI for both Django 4.2 and Django 3.2 to contain backward compatibility.

  • Creating a PR after updating the workflows would automatically start executing tests against Django 4.2.

• Fix Django 4.0 and Django 4.1 Deprecation Warnings

  • When running tests against Django 3.2, there would be Django 4.* Deprecation warnings in the test logs.

  • You can use third party django-upgrade tool to fix most of the deprecation warnings and refactor your code automatically.

  • If there are still any deprecation warnings left, you can go through the edx-platform deprecation issues to identify any specific warning and the method to resolve it.

• Update Requirements

  • Update the pinned Django version in the requirements to Django==4.2

• Update Requirements

  • Update the pinned Django version in the requirements to Django==4.2

  • You’ll need to override the common constraints in the make upgrade compile target for upgrading the dependencies. For that the approach can be used to override the Django<3.2 common constraint.

  • Run make upgrade to update all dependencies for Django 4.2.

• Contain Backward Compatibility Run tests successfully with Django 34.2

  • The current plan is to ship the quince release with the support of both Django 3.2 and Django 4.2

  • If upgrading requirements breaks any test for Django 3.2 then it should be handled accordingly to keep the backward compatibility with Django 3.2.

  • Add conditional checks wherever needed to still have support for Django 3.2.

  • Creating a PR after updating the workflows would automatically start executing tests against Django 4.2.

  • Fix all the failing tests to make the CI runners green with Django 4.2.

• Update IDA status

  • Update the repo support field in the IDA Upgrade Sheet

...

• The django.core.cache.backends.memcached.MemcachedCache backend is removed.

• See the Changelog for details.

• See the issue for details and all the efforts made to resolve this issue in edx-platform.

  • Some PRs would also be needed in edx-internal and sandbox-internal to update respective configurations.

New Migrations when upgrading to Django 4.2

• When running make migrations after upgrading to Django 4.2, following migrations will be created so this needs to be handled accordingly for each service to avoid any down time when deploying the service with Django 4.2 on stage and production

  • https://docs.djangoproject.com/en/4.2/releases/4.0/#migrations-autodetector-changes

  • https://docs.djangoproject.com/en/4.2/releases/4.1/#migrations

  • https://docs.djangoproject.com/en/4.2/releases/4.2/#index-together-option-is-deprecated-in-favor-of-indexes

Major Changes in Django 4.* releases

...