[thecardcheat]

That's surprising to me as I have updated a large production Django code-base on my own for every version from 1.5 to 2.0 and it has never taken me more than a day, with an equal or lesser (typically lesser) amount of time dedicated to deprecations when I updated to the previous version. Any blockers past that point have always been due to slow-to-update third-party libraries.

The Python 3 update took longer and had a longer legacy of surprise breakages, but I don't ding Django for following the intended life cycle of Python.

[jordigh]

> That's surprising to me

I'm surprised you're surprised. Have you seen the size of the breaking changes documented with each release notes? We typically hit about 10 of these changes per release, sprinkled all over our code.

https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar...

https://docs.djangoproject.com/en/2.0/releases/1.9/#backward...

https://docs.djangoproject.com/en/2.0/releases/1.8/#backward...

And those are just the intentional breaks. We find a lot of unintentional breakage too, and sometimes we accidentally use undocumented stuff which of course also isn't documented when it breaks. Each Django release has added an average of 32 commits per release for the past four releases just to deal with the version upgrade.

[collinmanderson]

Some things to do that could help everyone (this is what I do):

If documented stuff changes, Please report it (though that likely means testing against the alpha / beta versions (or just master). Keep Django honest.

If you find yourself using undocumented features, consider documenting them; that way they’re held to backward compatibility.

Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.

Disclaimer: Core dev now, though I had this attitude before that too.

[jordigh]

> Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.

I really don't want to be sucked into Django's drama:

https://us.pycon.org/2015/schedule/presentation/381/

I've encountered very little sympathy from Django developers. Everyone seems to have just accepted that it breaks often and it's totally my fault for not keeping up with the breaking changes. Everyone seems to think that Django breaking compatibility all over the place is good, proper, acceptable, and inevitable. Nothing is sacred, anything can break, and make sure you go through that list each release to see what you have to change in your code.

This makes me sad and frustrated.

http://stevelosh.com/blog/2012/04/volatile-software/

[collinmanderson]

I hear you, and I've heard others say the same.

I think it would help if you bring it up on the Django-developers mailing list, if you haven't yet. I think that would help raise awareness about the issue, and I hope it would lead to some policy changes.

[rtpg]

My guess here is that still being in Python 2 makes this more difficult.

If you're in Python 2 the bytes/str story is still mixed up, so API solidification happening in Django iteratively (in preparation for Django 2.0) will likely break a good amount of your code.

Inversely, we moved over to Py3 in the 1.7 days so we were spared some pain on that end.