I've upgraded a large (~700K LOC) Django project across several versions (1.5-1.9). I think Django does a reasonably good job of maintaining a good upgrade path

I've upgraded a large (~700K LOC) Django project across several versions (1.5-1.9). I think Django does a reasonably good job of maintaining a good upgrade path, though they frequently break backwards compatibility, and at a pretty fast rate (now 8 months release cycles, which barely gives the community to catch up). Some of the changes like module renames seem pointless from an end user perspective, so it feels like the django core team shovels busywork onto users. I also find their method naming policies annoying, since they don't annotate "unsupported" features in any way (eg with an _attribute, and also some _attributes ARE supported). This makes it difficult to figure out whether you're "staying within the lines" of their support policy. I keep a checkout of the django repo around so I can grep the docs for mentions of a method before I use it. That said, having started on updating that same codebase to Python 3, the Django team tries hard to provide the KEY thing you need to seamlessly update a codebase: a version which can support both incompatible features. Without this, you need to have one giant branch with a bunch of renames and other changes. They actually introduce deprecation warnings, and have something non-deprecated you can use in the same version. I think if Python core had introduced a version of Python including both versions of all the module renames with deprecation warnings, the community would be much further along on the upgrade path.