6 ms·

There have been lots of breaking changes along the way. Django is pretty good at giving developers a heads up of what is deprecated and slated for removal, but

by bebop 9y ago

There have been lots of breaking changes along the way. Django is pretty good at giving developers a heads up of what is deprecated and slated for removal, but there have been lots of growing pains in the 1.x release cycles.

jordigh 9y ago
I really dread upgrading Django. We have a codebase that has been with us since the 1.3 days and each time there's an upgrade, someone on the team sets about one month aside to deal with all of the breakage. You could say that this is our fault for "doing it wrong" but we just wanna get stuff done. Sometimes the only way to do it that we could figure out was by doing something that Django later decided we shouldn't have done. Going to Python 3 is going to be the biggest annoyance yet.
- mundanevoice 9y ago
  I have been writing Django professionally since 2013, It's ain't that bad. Our codebase is huge & it never takes us more than 2 weeks to do it and lately, it has always gotten less and less. Wonder if the issue is with your codebase that it breaks so much on upgrades. Python3 upgrade is a task, agreed. But it actually gives good returns. The language is nicer to write in and we even saved some memory and CPU on the same load after the upgrade. So highly recommended.
  - ngrilly 9y ago
    Saved some memory and CPU after the upgrade? Could you give some numbers?
    - gspetr 9y ago
      https://thenewstack.io/instagram-makes-smooth-move-python-3/ https://thenewstack.io/instagram-makes-smooth-move-python-3/ How has Python 3 performed since then? "Ding: We did not have performance gain expectations for Python 3 right out of the box. So it was a pleasant surprise to see 12 percent CPU savings (on uswgi/Django) and 30 percent memory savings (on celery). It’s only been four months since rollout, we don’t expect to see constant 10 percent performance improvement, but that was a very promising start."
      - orf 9y ago
        Removing the 2/3 compatibility shims saves a lot of code and runtime cost, that could be a contributing factor.
        ngrilly 9y ago
        Good point.
- trowawee 9y ago
  Huh. At my last job, we went from 1.7 to 1.11 and while it wasn't seamless, I suspect we spent about that much actual work time making upgrade-related changes/fixes (120ish person-hours) for all of those upgrades combined. We hadn't jumped to Python 3/Django 2 before I left, but we were starting to plan for it. I knew it was going to be painful, but that's part of the cost of holding out for so long, isn't it?
- thecardcheat 9y ago
  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.
  - rtpg 9y ago
    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.
  - jordigh 9y ago
    > 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/#backwards-incompatible-changes-in-1-10 https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar... https://docs.djangoproject.com/en/2.0/releases/1.9/#backwards-incompatible-changes-in-1-9 https://docs.djangoproject.com/en/2.0/releases/1.9/#backward... https://docs.djangoproject.com/en/2.0/releases/1.8/#backwards-incompatible-changes-in-1-8 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 9y ago
      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.
- allover 9y ago
  > You could say that this is our fault for "doing it wrong" Do you have decent test coverage and use tox to run your tests against multiple versions of Django? If not I can recommend this approach from experience.
- paulie_a 9y ago
  I am currently upgrading a code base from 1.4 to 1.5.12 as a weekend project. On the plus side the original authors managed to avoid using Django features so that makes it a bit easier. Someone actually wrote their own ORM in the process
rectangletangle 9y ago
Given the functionality Django offers, the "cost" of the growing pains has been well worth it. Especially for the 1.7 upgrade that happened a while back (when they introduced the new migrations framework). Relative to modern JS projects, where whole frameworks are switched out quarterly, maintaining a Django project is trivial. I really like the new URL syntax they introduced. I'd been relying on 3rd party libraries like Django REST for years at this point, because the raw regex URL syntax was always annoying and verbose. The new syntax looks well executed. I've been working with 1.11 and Python 3, so I'm looking forward to upgrading soon.

by bebop 9y ago

jordigh 9y ago

I really dread upgrading Django. We have a codebase that has been with us since the 1.3 days and each time there's an upgrade, someone on the team sets about one month aside to deal with all of the breakage. You could say that this is our fault for "doing it wrong" but we just wanna get stuff done. Sometimes the only way to do it that we could figure out was by doing something that Django later decided we shouldn't have done. Going to Python 3 is going to be the biggest annoyance yet.

mundanevoice 9y ago
I have been writing Django professionally since 2013, It's ain't that bad. Our codebase is huge & it never takes us more than 2 weeks to do it and lately, it has always gotten less and less. Wonder if the issue is with your codebase that it breaks so much on upgrades. Python3 upgrade is a task, agreed. But it actually gives good returns. The language is nicer to write in and we even saved some memory and CPU on the same load after the upgrade. So highly recommended.
- ngrilly 9y ago
  Saved some memory and CPU after the upgrade? Could you give some numbers?
  - gspetr 9y ago
    https://thenewstack.io/instagram-makes-smooth-move-python-3/ https://thenewstack.io/instagram-makes-smooth-move-python-3/ How has Python 3 performed since then? "Ding: We did not have performance gain expectations for Python 3 right out of the box. So it was a pleasant surprise to see 12 percent CPU savings (on uswgi/Django) and 30 percent memory savings (on celery). It’s only been four months since rollout, we don’t expect to see constant 10 percent performance improvement, but that was a very promising start."
    - orf 9y ago
      Removing the 2/3 compatibility shims saves a lot of code and runtime cost, that could be a contributing factor.
      - ngrilly 9y ago
        Good point.
trowawee 9y ago
Huh. At my last job, we went from 1.7 to 1.11 and while it wasn't seamless, I suspect we spent about that much actual work time making upgrade-related changes/fixes (120ish person-hours) for all of those upgrades combined. We hadn't jumped to Python 3/Django 2 before I left, but we were starting to plan for it. I knew it was going to be painful, but that's part of the cost of holding out for so long, isn't it?
thecardcheat 9y ago
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.
- rtpg 9y ago
  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.
- jordigh 9y ago
  > 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/#backwards-incompatible-changes-in-1-10 https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar... https://docs.djangoproject.com/en/2.0/releases/1.9/#backwards-incompatible-changes-in-1-9 https://docs.djangoproject.com/en/2.0/releases/1.9/#backward... https://docs.djangoproject.com/en/2.0/releases/1.8/#backwards-incompatible-changes-in-1-8 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 9y ago
    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.
allover 9y ago
> You could say that this is our fault for "doing it wrong" Do you have decent test coverage and use tox to run your tests against multiple versions of Django? If not I can recommend this approach from experience.
paulie_a 9y ago
I am currently upgrading a code base from 1.4 to 1.5.12 as a weekend project. On the plus side the original authors managed to avoid using Django features so that makes it a bit easier. Someone actually wrote their own ORM in the process

rectangletangle 9y ago

Given the functionality Django offers, the "cost" of the growing pains has been well worth it. Especially for the 1.7 upgrade that happened a while back (when they introduced the new migrations framework). Relative to modern JS projects, where whole frameworks are switched out quarterly, maintaining a Django project is trivial. I really like the new URL syntax they introduced. I'd been relying on 3rd party libraries like Django REST for years at this point, because the raw regex URL syntax was always annoying and verbose. The new syntax looks well executed. I've been working with 1.11 and Python 3, so I'm looking forward to upgrading soon.