7 ms·

Respect to the Django team that even after 12 years they have only one major version shift (which seems to only because of dropping support for Python 2) and th

Respect to the Django team that even after 12 years they have only one major version shift (which seems to only because of dropping support for Python 2) and the backwards incompatible changes are minimal.

ameliaquining 9y ago
The plan going forward is to make every third release semver-major, but these will still be incremental releases. The semver-major ones will be backwards-incompatible only in that they'll drop support for features that had already been deprecated for at least two releases.
- collinmanderson 9y ago
  Right. It’s a change in version numbering scheme. Not any major backwards compatibility. It will bump every two years from now on.
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?
- 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.

ameliaquining 9y ago

The plan going forward is to make every third release semver-major, but these will still be incremental releases. The semver-major ones will be backwards-incompatible only in that they'll drop support for features that had already been deprecated for at least two releases.

collinmanderson 9y ago
Right. It’s a change in version numbering scheme. Not any major backwards compatibility. It will bump every two years from now on.

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?
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.