...
- Check dependencies for compatibility. Sometimes dependencies maintained by third-parties (or even edX!) are not compatible with updated versions of Django. Determine which are not, and create a list of those dependencies. At a minimum, reach out to the maintainers requesting if/when an update will be released. Depending on the the timeline of the upgrade of the dependency, and our own urgency to start using the new version of Django, we have a few options:
- Work with the maintainers to update/release the library.
- Deploy from a fork until the main repository is updated.
- Replace the library with an alternative.
- Resolve all deprecation warnings that are logged for the current version of Django. This should ensure that features removed in the future version of Django are no longer used. Under no circumstances should you resolve deprecation issues by disabling deprecation warnings!
- Read the Django release notes...twice! Pay special attention to features that have been removed and/or deprecated.
- Release these changes independently of the actual Django upgrade to limit the scope of any potential issues.
...
- Read the release notes again.
- Upgrade Django in the appropriate requirements file.
- Run
makemigrationsto generate any new migrations for Django-maintained tables (e.g. group/user tables).- If there are migrations that affect tables with a large number of rows (e.g. user tables), talk to DevOps to determine a release plan! Depending on the change, we may opt to fake the migration in production.
- If you do not know how many rows are in an affected table, talk to DevOps to get help finding this information! (Admitting you don't know before the release is very much preferred to doing so once the service goes down!)
- Loadtest the new changes. Ideally performance should improve or remain the same. More importantly, however, we want to execute the code in an environment with production-like data scale.
- Update the Open edX release notes at Open edX Release Planning. Open source maintainers will need to run similar, if not the same, processes we run to upgrade. Update the release notes informing them of the upgrade and anything to be weary of (e.g. migrations affecting large tables).
- Release the Django upgrade by itself. If it breaks, we know exactly what to revert to fix it.
...