mirror of https://github.com/zulip/zulip.git
36 lines
1.9 KiB
Markdown
36 lines
1.9 KiB
Markdown
|
# Upgrading Django
|
||
|
|
||
|
This article documents notes on the process for upgrading Zulip to
|
||
|
new major versions of Django. Here are the steps:
|
||
|
|
||
|
* Carefully read the Django upstream changelog, and `git grep` to
|
||
|
check if we're using anything deprecated or significantly modified
|
||
|
and put them in an issue (and then starting working through them).
|
||
|
Also, note any new features we might want to use after the upgrade,
|
||
|
and open an issue listing them;
|
||
|
[example](https://github.com/zulip/zulip/issues/2564).
|
||
|
* Start submitting PRs to do any deprecation-type migrations that work
|
||
|
on both the old and new version of Django. The goal here is to have
|
||
|
the actual cutover commit be as small as possible, and to test as
|
||
|
much of the changes for the migration as we can independently from
|
||
|
the big cutover.
|
||
|
* Check the version support of the third-party Django packages we use
|
||
|
(`git grep django requirements/` to see a list), upgrade any as
|
||
|
needed and file bugs upstream for any that lack support. Look into
|
||
|
fixing said bugs.
|
||
|
* Look at the pieces of Django code that we've copied and then
|
||
|
adapted, and confirm whether Django has any updates to the modified
|
||
|
code we should apply. Partial list:
|
||
|
* SessionMiddleware in `django.contrib.sessions.middleware` (we fork `get_response`).
|
||
|
* `CursorDebugWrapper`, which we have a modified version of in
|
||
|
`zerver/lib/db.py`. See
|
||
|
[the issue for contributing this upstream](https://github.com/zulip/zulip/issues/974)
|
||
|
* `PasswordResetForm` and any other forms we import from
|
||
|
`django.contrib.auth.forms` in `zerver/forms.py` (which has all of
|
||
|
our Django forms).
|
||
|
* `AsyncDjangoHandlerBase` in `zerver/tornado/handlers.py` is a very
|
||
|
small patch on `base.BaseHandler`; see the comments with `BY
|
||
|
ZULIP` for our changes (unfortunately now more different due to
|
||
|
style differences and mypy annotations). This configurability
|
||
|
should also be contributed to Django upstream.
|