Making django-upgrade part of deprecation policy and release cycle.

[carltongibson]

Hey @adamchainz

The @steering_council wanted to begin a discussion with you about making django-upgrade part of the deprecation policy and release cycle.

The idea is pretty simple: If we want to make a breaking change, not only do we document it and provide a backwards compatible shim, and go through the deprecation process, but we also make sure there’s a django-upgrade fixer provided to make the vast majority of such changes entirely automatic. We make sure that’s all documented, with clear instructions on the release notes etc, and so on.

We think django-upgrade is a big step forward, and if we can advance it, there’s (at least) a hope that we can be slightly more ambitious in making modernisations to Django’s API.

It’s probably too near to target 6.1, but maybe in time for 6.2 is reasonable. A discussion here, followed by a DEP to codify what’s said seems like a good approach. (But very much exploratory at this stage.)

At first pass, is this something you’d be keen to see happen? That’s the most important thing really.

So, some key questions that might come up:

How will the project governance continue? I assume you still want to be involved now, but five years hence (or whenever) you might want to step away, so that needs to be something we’ve considered.

How are we going to create the fixers. Will the steering council, fellows, or some other group aim to help out writing and testing fixers? I imagine we need an expert group that can help create such. The ast/tokenization approach is a little bit complicated. It’s likely we need some documentation and tips on how to understand the code. We need a strategy for making sure there are enough people familiar with django-upgrade to make sure we’re sustainable here.

You seem to have the repo management, tooling, and releases pretty well sorted — it would be good to make sure we don’t regress on the work you’ve done there. Again, while you’re happy to keep doing it, I don’t see much of a problem there, but the question of succession should at least be addressed in outline. (It’s about supporting you.)

What else? I’m sure there’s more This is just to get the ball moving.

Kind Regards,

Carlton

[jacobtylerwalls]

Lovely.

I haven’t peeked at the django-upgrade internals, but just wanted to chime in to say that I have some experience reviewing PRs that make use of AST analysis (I’ve worked pylint/astroid in the past). Happy to share as much knowledge as I can there. So, yes, we need Adam’s help to lead & document & recruit, but I think we can do it

[adamchainz]

Hey! Sorry for the delay here…

@carltongibson

At first pass, is this something you’d be keen to see happen?

Yes, totally!

@carltongibson

How will the project governance continue?

I propose that we form a Django team, perhaps callled the “upgrade path team”, who become responsible for the tool and generally thinking about deprecations. For example, they might help build tools like the @deprecate_posargs decorator that @medmunds made in Fixed #36477, Refs #36163 -- Added @deprecate_posargs decorator to si… · django/django@f42b89f · GitHub .

@carltongibson

How are we going to create the fixers. Will the steering council, fellows, or some other group aim to help out writing and testing fixers?

I guess it could be this team!

@carltongibson

The ast/tokenization approach is a little bit complicated.

It is, but it’s also the kind of problem where LLMs shine, so I think it is becoming more feasible for those without AST expertise to dive into.

@carltongibson

t’s likely we need some documentation and tips on how to understand the code.

Yes, totally! So far I’ve mostly pointed at folks at this video tutorial: https://www.youtube.com/watch?v=G1omxo5pphw . However, some written docs would be great.

@carltongibson

Again, while you’re happy to keep doing it, I don’t see much of a problem there, but the question of succession should at least be addressed in outline.

Yeah, sure. I do plan to maintain it for the foreseeable future, along with my other packages, all using a uniform setup. I’d be happy to help document some things, at least, so team members know how it works. There’d be a big intersection there with my Boost Your Django DX book, though! (At least, once I’ve updated the book to uv/ruff.)

@carltongibson

What else?

I think the list of resources to transfer and share ownership of would be:

1. The GitHub repo
2. The pre-commit.ci integration on GitHub
3. The ReadTheDocs project
4. The PyPI project

Presumably to Django’s org where applicable, and granting access to the at least fellows.

Let’s do this!