21 ms·

Django 1.10 released

227 points by hrayr 10y ago

hrayr 10y ago
Some of the highlights: - Full text search for PostgreSQL. - New-style middleware to solve the lack of strict request/response layering of the old-style of middleware. - Official support for Unicode usernames.
hrayr 10y ago
I'm still stuck with Django 1.4 for one of my projects, it's such a big hurdle to upgrade it. I wonder if it's worth to just straight up rewrite it in 1.10.
- gtaylor 10y ago
  1.4 to 1.5 is the really painful upgrade. The rest are much less so. Especially after 1.6.
  - St-Clock 10y ago
    Until you hit the migrations in 1.7. But you are right. At my previous job, I spent countless hours getting from 1.4 to 1.5, but the step from 1.5 to 1.6 was relatively painless.
    - merb 10y ago
      if you can screw your old migrations it's not a big deal.
    - mangeletti 10y ago
      For others: https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdoption-migrate--fake-initial https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdo...
      - St-Clock 10y ago
        This was introduced in 1.8 (which is great if you move to 1.8 or beyond), but if you are trying to go step by step, 1.7 was not a fun release to migrate to. There were also many problems with custom user model and the like. 1.7 was a very important release in the history of Django, just not a fun release to move to if you had a large codebase.
- Walkman 10y ago
  It's better to do it step by step: 1.4 to 1.5, 1.5 to 1.6, etc. You need to go through the release notes and have a good test coverage.
  - bdr 10y ago
    This. Go through the deprecation lists and backwards incompatibility lists item by item. Thankfully, they're very thoroughly done. It probably won't take as long as you think!
- mamcx 10y ago
  Depends. Re-write help in clean code way more that just a upgrade ('cause is a bigger refactoring), but could take longer time. Normally I prefer that, and translate code manually. even more if the jump is big. Except if the goal is just stay current.
- bebop 10y ago
  I agree with the advice of moving the project forward release by release. With that said, it might be useful to create a new project from the django-admin startproject template, and then add your apps back in. Starting at 1.7, getting everything working and then doing it again with 1.10 would be my recommendation. YMMV though.
- stable-point 10y ago
  As others have said, going release-by-release is the way to go. I migrated a project from 1.4 to 1.8 (LTS to LTS) over the course of a few months. It wasn't trivial, but it wasn't too difficult either. The deprecation notices are usually (always?) accompanied by the code giving `DeprecationWarning` messages. These are silenced by default, but can be enabled by setting the environment variable: `PYTHONWARNING=d`. After upgrading to each major version, I'd recommend running with warnings enabled for a little while (in addition to reading the release notes), to see what may bite you at the next jump.
- ergo14 10y ago
  It is quite scary for me to read that people have serious issues upgrading their frameworks, wouldn't it be better to use pyramid (or flask eventually) instead? It is very mature and well supported - and the upgrades are usually painless since you can upgrade all the components separately so sqlalchemy for ORM or Jinja2 for templates - whenever you feel you are ready. You will not get things like admin panel as a downside though.
  - jsmeaton 10y ago
    You get similar issues with libraries that you use for flask or pyramid too though, if you don't upgrade it for 4 years.
- asimuvPR 10y ago
  No need to rewrite if you have a good codebase. Just go upgrade one version at a time until you reach your target version. Its not too bad.
dchuk 10y ago
As a Rails dude...is there any reason for me to learn Django at all? Everything I've heard about it is that it provides a lot of sane defaults (like Rails) but has much less "magic" than Rails is typically thought to have. And if the answer to my question is yes, what books/tutorials/screencasts/courses to people recommend to get started with?
- varikin 10y ago
  I don't see why you would need to learn it unless you wanted/needed to work on Python web projects. It is a fairly standard, opinionated web framework. I don't think there is anything unique enough to make learning it special.
- ronjouch 10y ago
  If you're familiar with Ruby/Rails, I don't see any reason to switch. They're both good large frameworks. As you said, yes Django may sometimes feel a bit less "magic", due to Python's "explicit is better than implicit" motto, https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/ If you want to give it a try anyway, Two Scoops of Django is a wonderful book, by two warm contributors from the Python community. https://www.twoscoopspress.com/ https://www.twoscoopspress.com/
- nprescott 10y ago
  I can't answer your first question, they're similar high-level web frameworks - do you want to learn another? As for books, I'd recommend Two Scoops of Django[1]. Between that and the tutorial you should be up to speed pretty quickly. Maybe read it and see if anything appeals to you about Django? [1]: https://www.twoscoopspress.com/ https://www.twoscoopspress.com/
- Walkman 10y ago
  My suggestion: don't bother. The "less magic" things comes because of Python's explicitness (not because of Django at all).
  - dguaraglia 10y ago
hrayr 10y ago
Looks like channels was not included in 1.10. Is there still a plan to package it with Django or is it better served to be a stand alone app for now? According to channels' documentation: > You can install Channels as a library for Django 1.8 and 1.9, and it (should be) part of Django 1.10.
- heyts 10y ago
  It was withdrawn from the 1.10 release about 3 months ago, I think: https://groups.google.com/forum/#!msg/django-developers/QRd4v7OErT8/oTv4APoOAwAJ https://groups.google.com/forum/#!msg/django-developers/QRd4...
  - ataylor32 10y ago
    Also see: https://groups.google.com/forum/#!topic/django-developers/24DGLVVRV_s https://groups.google.com/forum/#!topic/django-developers/24...
- czk 10y ago
  To quote Channel's author, Andrew Godwin: "I will take the path-most-trodden for me and large Django features, which is to run it as an external package, compatible with 1.8 through 1.10 (which the package already is), and let it mature and develop outside of core, before coming round to look again at inclusion for 1.11 or 2.0."
EDevil 10y ago
In the middle of the changes is an important security fix for sites that take file uploads: https://substance.brpx.com/hardening-django-one-dos-at-a-time-30bbfc8c853 https://substance.brpx.com/hardening-django-one-dos-at-a-tim...
Flimm 10y ago
Here are the release notes, they are excellently written, just like the Django docs are excellently written. I continue to be impressed. https://docs.djangoproject.com/en/1.10/releases/1.10/ https://docs.djangoproject.com/en/1.10/releases/1.10/
orf 10y ago
Shame about Channels, but I see the logic in not including it. Django is pretty awesome as a backend, and while it's not a 'cool' framework anymore (I feel old!) it's amazing for writing back-office applications. I use it as an API backend with Django-rest-framework. The advantage is you get ridiculous amounts of packages that all integrate with Django that does pretty much anything you want. Also the ORM doesn't suck now so that's a bonus.
- graffitici 10y ago
  Why did the ORM suck before? Were there major changes done to the ORM?
  - sneakymichael 10y ago
    Potentially in part because, until fairly recently (version 1.7 I believe), Django didn't have support for database schema migration built-in- https://docs.djangoproject.com/en/1.7/topics/migrations/ https://docs.djangoproject.com/en/1.7/topics/migrations/
    - graffitici 10y ago
      I see. If that's the only reason, not sure if it's a major problem with the ORM, given that you could use South instead with almost the same outcome.
      - swinglock 10y ago
        The built-in migration code is even the continuation of South. https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django/description https://www.kickstarter.com/projects/andrewgodwin/schema-mig...
  - orf 10y ago
    Was pretty limited and very very inferior to SQLAlchemy. It still is, but it's bearable. As an example off the top of my head when I started with Django you couldn't bulk create objects, if you wanted to create 100 records it needed 100 separate INSERT statements. That got old fast. Edit: Not sure why the downvotes, perhaps comment on why you think I'm wrong?
stenius 10y ago
Edit: looks like this is now the 2nd to last release to support Python2. Original: It doesn't mention it on this page, but this is also planned to be the last Django release to support python2. Django 2 will require python3.
- sold 10y ago
  No, that's 1.11 (a LTS release)
- davb 10y ago
  This is great news. Now that the transition is in full swing, it's encouraging to see more projects adopt a Python 3 First attitude. I only wish Ansible would catch up (a recent release broke the core Python 3 support that was there, and no-one seemed to care as Py3 isn't yet officially supported).
  - brianwawok 10y ago
    Ansible problem is 100s of libs that are python2 only. Sysadmins never got python3...
- evansd 10y ago
  I believe it's the last-but-one release to support Python 2. Django 1.11 LTS (scheduled for release April 2017) is planned to be the final 2-compatible version. https://www.djangoproject.com/download/#supported-versions https://www.djangoproject.com/download/#supported-versions
plumeria 10y ago
I wonder why this release didn't include the class-based auth views (https://github.com/django/django/blob/1.10/django/contrib/auth/views.py https://github.com/django/django/blob/1.10/django/contrib/au... vs https://github.com/django/django/blob/master/django/contrib/auth/views.py https://github.com/django/django/blob/master/django/contrib/...)
- alasdairnicol 10y ago
  Django has a time based release schedule [1]. The class based authentication views weren't committed until after the feature freeze for the 1.10 alpha.
  - alasdairnicol 10y ago
    [1]: https://docs.djangoproject.com/en/1.9/internals/release-process/#release-process https://docs.djangoproject.com/en/1.9/internals/release-proc...
deleted 10y ago
[deleted]
spdustin 10y ago
As someone who's picked up Python only in the last few years, Django is amazing. I'm particularly fond of Django CMS. Does anyone know of a working "static site generator" for Django that works with Django CMS? Or maybe Wagtail? Something that would build out the static HTML pages ready to deploy to S3. Django CMS (thanks to Django itself) has a wonderfully robust back-office UI, and I feel like my Google-fu has failed me in finding that last puzzle piece to static site nirvana.
- clintonb 10y ago
  See http://docs.wagtail.io/en/v1.5.3/reference/contrib/staticsitegen.html http://docs.wagtail.io/en/v1.5.3/reference/contrib/staticsit... for Wagtail. I've been experimenting with django-bakery and wagtailbakery with much success.
  - spdustin 10y ago
    How did I miss that? Thanks so much!
- c17r 10y ago
  * django-medusa https://github.com/mtigas/django-medusa https://github.com/mtigas/django-medusa * django-bakery https://github.com/datadesk/django-bakery https://github.com/datadesk/django-bakery * django-freeze https://github.com/fabiocaccamo/django-freeze https://github.com/fabiocaccamo/django-freeze * django-staticgen https://github.com/mishbahr/django-staticgen https://github.com/mishbahr/django-staticgen
ben_jones 10y ago
Recently after a 6 year hiatus from Django, I've experimented migrating a smallish flask API and wholly cow did the Django API get CLEANER. Like my god people talk about Django as if it hasn't changed in 6 years but it feels to me like many of the warts got removed and it's just down right pleasant to work with. I love Flask but there is just a little too much boiler plate when you compare it to modern Django for even small projects (IMO).
encoderer 10y ago
If there are any Django masters in the building: If you were starting a project today would you use 1.10 or stick with the LTS release (1.8)? I have a fairly mature django project using 1.6 that I would be borrowing a bit from, and my experience not upgrading off 1.6 due to pain makes it feel like an LTS path might be a good choice?
- OriginalPenguin 10y ago
  If you are going to be around and have time to actively upgrade the project every time a new release comes out until it's running on the next version of LTS, I'd choose 1.10. If you are just going to write it, and not constantly improve and upgrade it until the next version of LTS, I'd choose the LTS.
  - encoderer 10y ago
    Thanks. It's not so much that we don't work on it, just that we work on product improvements that move the dial more than django upgrades. But you certainly accrue tech debt to do so.
- jsmeaton 10y ago
  The next LTS will be released in about 9 months. If you're willing to make a small upgrade at that time, I'd build on 1.10 and then upgrade to 1.11 LTS, which will give you 3 years (I think..) plus 9 months of 1.10 support. Moving from 1.8 to 1.11 shouldn't require any changes provided that you're running with 0 deprecation warnings on 1.8. The new release scheme means that if you're running on an LTS with no deprecation warnings, then you should be able to upgrade to the next LTS release with no changes (but lots of new deprecation warnings). Hope that helps. https://docs.djangoproject.com/es/1.9/internals/release-process/ https://docs.djangoproject.com/es/1.9/internals/release-proc...
  - ataylor32 10y ago
    > Moving from 1.8 to 1.11 shouldn't require any changes provided that you're running with 0 deprecation warnings on 1.8. Yes, this is how it's supposed to be. This agrees with Django's roadmap (see the "I’m the maintainer of a reusable application. Which Django versions should I support?" question at the bottom): https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ However, it depends on the third party apps you're using. I have a Django 1.9 site that uses django-mptt. The site was running warning-clean, but when I attempted to upgrade the site to Django 1.10, it broke because of this issue: https://github.com/django-mptt/django-mptt/issues/469 https://github.com/django-mptt/django-mptt/issues/469
hoodedfang 10y ago
Django has managed to avoid collapsing under its own weight and for that it should be commended. If you've invested time in less-opinionated microframeworks, you're probably better off just not going the Django route(no pun intended).

227 points by hrayr 10y ago

hrayr 10y ago

Some of the highlights: - Full text search for PostgreSQL. - New-style middleware to solve the lack of strict request/response layering of the old-style of middleware. - Official support for Unicode usernames.

hrayr 10y ago

I'm still stuck with Django 1.4 for one of my projects, it's such a big hurdle to upgrade it. I wonder if it's worth to just straight up rewrite it in 1.10.

gtaylor 10y ago
1.4 to 1.5 is the really painful upgrade. The rest are much less so. Especially after 1.6.
- St-Clock 10y ago
  Until you hit the migrations in 1.7. But you are right. At my previous job, I spent countless hours getting from 1.4 to 1.5, but the step from 1.5 to 1.6 was relatively painless.
  - merb 10y ago
    if you can screw your old migrations it's not a big deal.
  - mangeletti 10y ago
    For others: https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdoption-migrate--fake-initial https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdo...
    - St-Clock 10y ago
      This was introduced in 1.8 (which is great if you move to 1.8 or beyond), but if you are trying to go step by step, 1.7 was not a fun release to migrate to. There were also many problems with custom user model and the like. 1.7 was a very important release in the history of Django, just not a fun release to move to if you had a large codebase.
Walkman 10y ago
It's better to do it step by step: 1.4 to 1.5, 1.5 to 1.6, etc. You need to go through the release notes and have a good test coverage.
- bdr 10y ago
  This. Go through the deprecation lists and backwards incompatibility lists item by item. Thankfully, they're very thoroughly done. It probably won't take as long as you think!
mamcx 10y ago
Depends. Re-write help in clean code way more that just a upgrade ('cause is a bigger refactoring), but could take longer time. Normally I prefer that, and translate code manually. even more if the jump is big. Except if the goal is just stay current.
bebop 10y ago
I agree with the advice of moving the project forward release by release. With that said, it might be useful to create a new project from the django-admin startproject template, and then add your apps back in. Starting at 1.7, getting everything working and then doing it again with 1.10 would be my recommendation. YMMV though.
stable-point 10y ago
As others have said, going release-by-release is the way to go. I migrated a project from 1.4 to 1.8 (LTS to LTS) over the course of a few months. It wasn't trivial, but it wasn't too difficult either. The deprecation notices are usually (always?) accompanied by the code giving `DeprecationWarning` messages. These are silenced by default, but can be enabled by setting the environment variable: `PYTHONWARNING=d`. After upgrading to each major version, I'd recommend running with warnings enabled for a little while (in addition to reading the release notes), to see what may bite you at the next jump.
ergo14 10y ago
It is quite scary for me to read that people have serious issues upgrading their frameworks, wouldn't it be better to use pyramid (or flask eventually) instead? It is very mature and well supported - and the upgrades are usually painless since you can upgrade all the components separately so sqlalchemy for ORM or Jinja2 for templates - whenever you feel you are ready. You will not get things like admin panel as a downside though.
- jsmeaton 10y ago
  You get similar issues with libraries that you use for flask or pyramid too though, if you don't upgrade it for 4 years.
asimuvPR 10y ago
No need to rewrite if you have a good codebase. Just go upgrade one version at a time until you reach your target version. Its not too bad.

dchuk 10y ago

As a Rails dude...is there any reason for me to learn Django at all? Everything I've heard about it is that it provides a lot of sane defaults (like Rails) but has much less "magic" than Rails is typically thought to have. And if the answer to my question is yes, what books/tutorials/screencasts/courses to people recommend to get started with?

varikin 10y ago
I don't see why you would need to learn it unless you wanted/needed to work on Python web projects. It is a fairly standard, opinionated web framework. I don't think there is anything unique enough to make learning it special.
ronjouch 10y ago
If you're familiar with Ruby/Rails, I don't see any reason to switch. They're both good large frameworks. As you said, yes Django may sometimes feel a bit less "magic", due to Python's "explicit is better than implicit" motto, https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/ If you want to give it a try anyway, Two Scoops of Django is a wonderful book, by two warm contributors from the Python community. https://www.twoscoopspress.com/ https://www.twoscoopspress.com/
nprescott 10y ago
I can't answer your first question, they're similar high-level web frameworks - do you want to learn another? As for books, I'd recommend Two Scoops of Django[1]. Between that and the tutorial you should be up to speed pretty quickly. Maybe read it and see if anything appeals to you about Django? [1]: https://www.twoscoopspress.com/ https://www.twoscoopspress.com/
Walkman 10y ago
My suggestion: don't bother. The "less magic" things comes because of Python's explicitness (not because of Django at all).
- dguaraglia 10y ago

hrayr 10y ago

Looks like channels was not included in 1.10. Is there still a plan to package it with Django or is it better served to be a stand alone app for now? According to channels' documentation: > You can install Channels as a library for Django 1.8 and 1.9, and it (should be) part of Django 1.10.

heyts 10y ago
It was withdrawn from the 1.10 release about 3 months ago, I think: https://groups.google.com/forum/#!msg/django-developers/QRd4v7OErT8/oTv4APoOAwAJ https://groups.google.com/forum/#!msg/django-developers/QRd4...
- ataylor32 10y ago
  Also see: https://groups.google.com/forum/#!topic/django-developers/24DGLVVRV_s https://groups.google.com/forum/#!topic/django-developers/24...
czk 10y ago
To quote Channel's author, Andrew Godwin: "I will take the path-most-trodden for me and large Django features, which is to run it as an external package, compatible with 1.8 through 1.10 (which the package already is), and let it mature and develop outside of core, before coming round to look again at inclusion for 1.11 or 2.0."

EDevil 10y ago

In the middle of the changes is an important security fix for sites that take file uploads: https://substance.brpx.com/hardening-django-one-dos-at-a-time-30bbfc8c853 https://substance.brpx.com/hardening-django-one-dos-at-a-tim...

Flimm 10y ago

Here are the release notes, they are excellently written, just like the Django docs are excellently written. I continue to be impressed. https://docs.djangoproject.com/en/1.10/releases/1.10/ https://docs.djangoproject.com/en/1.10/releases/1.10/

orf 10y ago

Shame about Channels, but I see the logic in not including it. Django is pretty awesome as a backend, and while it's not a 'cool' framework anymore (I feel old!) it's amazing for writing back-office applications. I use it as an API backend with Django-rest-framework. The advantage is you get ridiculous amounts of packages that all integrate with Django that does pretty much anything you want. Also the ORM doesn't suck now so that's a bonus.

graffitici 10y ago
Why did the ORM suck before? Were there major changes done to the ORM?
- sneakymichael 10y ago
  Potentially in part because, until fairly recently (version 1.7 I believe), Django didn't have support for database schema migration built-in- https://docs.djangoproject.com/en/1.7/topics/migrations/ https://docs.djangoproject.com/en/1.7/topics/migrations/
  - graffitici 10y ago
    I see. If that's the only reason, not sure if it's a major problem with the ORM, given that you could use South instead with almost the same outcome.
    - swinglock 10y ago
      The built-in migration code is even the continuation of South. https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django/description https://www.kickstarter.com/projects/andrewgodwin/schema-mig...
- orf 10y ago
  Was pretty limited and very very inferior to SQLAlchemy. It still is, but it's bearable. As an example off the top of my head when I started with Django you couldn't bulk create objects, if you wanted to create 100 records it needed 100 separate INSERT statements. That got old fast. Edit: Not sure why the downvotes, perhaps comment on why you think I'm wrong?

stenius 10y ago

Edit: looks like this is now the 2nd to last release to support Python2. Original: It doesn't mention it on this page, but this is also planned to be the last Django release to support python2. Django 2 will require python3.

sold 10y ago
No, that's 1.11 (a LTS release)
davb 10y ago
This is great news. Now that the transition is in full swing, it's encouraging to see more projects adopt a Python 3 First attitude. I only wish Ansible would catch up (a recent release broke the core Python 3 support that was there, and no-one seemed to care as Py3 isn't yet officially supported).
- brianwawok 10y ago
  Ansible problem is 100s of libs that are python2 only. Sysadmins never got python3...
evansd 10y ago
I believe it's the last-but-one release to support Python 2. Django 1.11 LTS (scheduled for release April 2017) is planned to be the final 2-compatible version. https://www.djangoproject.com/download/#supported-versions https://www.djangoproject.com/download/#supported-versions

plumeria 10y ago

I wonder why this release didn't include the class-based auth views (https://github.com/django/django/blob/1.10/django/contrib/auth/views.py https://github.com/django/django/blob/1.10/django/contrib/au... vs https://github.com/django/django/blob/master/django/contrib/auth/views.py https://github.com/django/django/blob/master/django/contrib/...)

alasdairnicol 10y ago
Django has a time based release schedule [1]. The class based authentication views weren't committed until after the feature freeze for the 1.10 alpha.
- alasdairnicol 10y ago
  [1]: https://docs.djangoproject.com/en/1.9/internals/release-process/#release-process https://docs.djangoproject.com/en/1.9/internals/release-proc...

deleted 10y ago

[deleted]

spdustin 10y ago

As someone who's picked up Python only in the last few years, Django is amazing. I'm particularly fond of Django CMS. Does anyone know of a working "static site generator" for Django that works with Django CMS? Or maybe Wagtail? Something that would build out the static HTML pages ready to deploy to S3. Django CMS (thanks to Django itself) has a wonderfully robust back-office UI, and I feel like my Google-fu has failed me in finding that last puzzle piece to static site nirvana.

clintonb 10y ago
See http://docs.wagtail.io/en/v1.5.3/reference/contrib/staticsitegen.html http://docs.wagtail.io/en/v1.5.3/reference/contrib/staticsit... for Wagtail. I've been experimenting with django-bakery and wagtailbakery with much success.
- spdustin 10y ago
  How did I miss that? Thanks so much!
c17r 10y ago
* django-medusa https://github.com/mtigas/django-medusa https://github.com/mtigas/django-medusa * django-bakery https://github.com/datadesk/django-bakery https://github.com/datadesk/django-bakery * django-freeze https://github.com/fabiocaccamo/django-freeze https://github.com/fabiocaccamo/django-freeze * django-staticgen https://github.com/mishbahr/django-staticgen https://github.com/mishbahr/django-staticgen

ben_jones 10y ago

Recently after a 6 year hiatus from Django, I've experimented migrating a smallish flask API and wholly cow did the Django API get CLEANER. Like my god people talk about Django as if it hasn't changed in 6 years but it feels to me like many of the warts got removed and it's just down right pleasant to work with. I love Flask but there is just a little too much boiler plate when you compare it to modern Django for even small projects (IMO).

encoderer 10y ago

If there are any Django masters in the building: If you were starting a project today would you use 1.10 or stick with the LTS release (1.8)? I have a fairly mature django project using 1.6 that I would be borrowing a bit from, and my experience not upgrading off 1.6 due to pain makes it feel like an LTS path might be a good choice?

OriginalPenguin 10y ago
If you are going to be around and have time to actively upgrade the project every time a new release comes out until it's running on the next version of LTS, I'd choose 1.10. If you are just going to write it, and not constantly improve and upgrade it until the next version of LTS, I'd choose the LTS.
- encoderer 10y ago
  Thanks. It's not so much that we don't work on it, just that we work on product improvements that move the dial more than django upgrades. But you certainly accrue tech debt to do so.
jsmeaton 10y ago
The next LTS will be released in about 9 months. If you're willing to make a small upgrade at that time, I'd build on 1.10 and then upgrade to 1.11 LTS, which will give you 3 years (I think..) plus 9 months of 1.10 support. Moving from 1.8 to 1.11 shouldn't require any changes provided that you're running with 0 deprecation warnings on 1.8. The new release scheme means that if you're running on an LTS with no deprecation warnings, then you should be able to upgrade to the next LTS release with no changes (but lots of new deprecation warnings). Hope that helps. https://docs.djangoproject.com/es/1.9/internals/release-process/ https://docs.djangoproject.com/es/1.9/internals/release-proc...
- ataylor32 10y ago
  > Moving from 1.8 to 1.11 shouldn't require any changes provided that you're running with 0 deprecation warnings on 1.8. Yes, this is how it's supposed to be. This agrees with Django's roadmap (see the "I’m the maintainer of a reusable application. Which Django versions should I support?" question at the bottom): https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ However, it depends on the third party apps you're using. I have a Django 1.9 site that uses django-mptt. The site was running warning-clean, but when I attempted to upgrade the site to Django 1.10, it broke because of this issue: https://github.com/django-mptt/django-mptt/issues/469 https://github.com/django-mptt/django-mptt/issues/469

hoodedfang 10y ago

Django has managed to avoid collapsing under its own weight and for that it should be commended. If you've invested time in less-opinionated microframeworks, you're probably better off just not going the Django route(no pun intended).