Django 2.0 alpha(docs.djangoproject.com)
docs.djangoproject.com
Django 2.0 alpha
https://docs.djangoproject.com/en/dev/releases/2.0?hnews
88 comments
If anyone wants to see "Database level -- on delete cascade", here's my PR to Django that's been open since July/August: https://github.com/django/django/pull/8661
Nothing against your PR, but the default cascade-on-delete behavior is my least favorite thing about Django. :(
You don't like that models.CASCADE fakes it with extra requests to the Db? Or you don't like that the default is models.CASCADE instead of something like models.DO_NOTHING? There's talk of making the on_delete kwarg required. In that world there would be no default :).
Some highlights from the pages:
"This alpha milestone marks a complete feature freeze."
"The current release schedule calls for a beta release in about a month and a release candidate about a month from then."
"The Django 1.11.x series is the last to support Python 2.7."
"This alpha milestone marks a complete feature freeze."
"The current release schedule calls for a beta release in about a month and a release candidate about a month from then."
"The Django 1.11.x series is the last to support Python 2.7."
Can someone recommend a learning path for building Django sites/apps to someone who has no web dev experience but uses python for scripting and workstation utilities? In particular, I use python for VFX/CGI scripting.
Start with the django-tutorial. Always start with the tutorial no matter what else they tell you. The django tutorial is excellent and cover most basics: https://docs.djangoproject.com/en/1.11/intro/tutorial01/
Then start writing your own application. When you have questions read the django documentantion. The django docs are the best documentantion I've ever seen, they are better than most books about django and should answer all your questions. The docs are so good I recommend reading them from start to finish - i.e download this off line version of the docs: https://media.readthedocs.org/pdf/django/1.11.x/django.pdf
and read it from cover to cover. You will not regret it.
Then start writing your own application. When you have questions read the django documentantion. The django docs are the best documentantion I've ever seen, they are better than most books about django and should answer all your questions. The docs are so good I recommend reading them from start to finish - i.e download this off line version of the docs: https://media.readthedocs.org/pdf/django/1.11.x/django.pdf
and read it from cover to cover. You will not regret it.
Thank you. My bookworm habits make this hard to accept, but your advice reflects my experience learning Python as well. The python.org tutorial was better than anything.
Would you also recommend learning CSS, HTTP, PHP _before_ the Django tutorials?
Would you also recommend learning CSS, HTTP, PHP _before_ the Django tutorials?
I strongly recommend the DjangoGirls tutorial:
https://tutorial.djangogirls.org/
It covers HTML, CSS, git, etc. in addition to teaching you Django.
https://tutorial.djangogirls.org/
It covers HTML, CSS, git, etc. in addition to teaching you Django.
I also like that tutorial, but the name is a bit unfortunate. I recommended it to a woman and she quickly accused me of "giving her a dumbed down tutorial for girls". I had to convince her that the site is actually very good.
this is great advice. thank you
I went from MEL scripting to Python to PHP to Python / Django.
Coming from VFX will give you a different perspective compared to other compsci types IMO. Especially if you've worked with things procedurally.
In the end with Django it's more than just Python but other than controlling ornery ORM generated SQL its pretty easy to work with on all fronts and has PHENOMENAL documentation.
Hit me up I twitter @leetrout if you want to chat more.
Coming from VFX will give you a different perspective compared to other compsci types IMO. Especially if you've worked with things procedurally.
In the end with Django it's more than just Python but other than controlling ornery ORM generated SQL its pretty easy to work with on all fronts and has PHENOMENAL documentation.
Hit me up I twitter @leetrout if you want to chat more.
Thank you. I learned to code with C# in Unity.
These things are what I am scared of.
These things are what I am scared of.
Buddy Lindsey's Godjango.com has some good short videos that take you through the site building process (both topic based and a few project based ones)
Learn html, css and some basic HTTP, the read the Django docs.
The courses at RealPython.com look good.
Can someone who uses Django, review this release? What are the most anticipated changes etc?
Not an expert by any means but to me the biggest change is no more Python 2.
> Django 2.0 supports Python 3.4, 3.5, and 3.6. We highly recommend and only officially support the latest release of each series.
People should not write new code in Python 2 at all. If you're learning Python today, I'd say pretend Python 2 doesn't exist. Use python3-venv and renounce the baggage of the past.
> Django 2.0 supports Python 3.4, 3.5, and 3.6. We highly recommend and only officially support the latest release of each series.
People should not write new code in Python 2 at all. If you're learning Python today, I'd say pretend Python 2 doesn't exist. Use python3-venv and renounce the baggage of the past.
Doing VFX pipeline dev here and none of the softwares support 3 yet. Houdini/3ds Max/Maya are all 2.7 only.
I have not even seen mention of moving to 3.
I have not even seen mention of moving to 3.
What are they planning to do when the support for Python 2 runs out and people remind them they had a decade in which to start a port but didn't?
I have the same question. If I remember right, it's going to happen in 2020.
I don't work with a studio yet but studios who buy the software don't seem too worried for some reason, even though their pipelines depend on it. Maybe someone else can offer better insight. As someone wanting to go into pipeline development, I am very curious.
I don't work with a studio yet but studios who buy the software don't seem too worried for some reason, even though their pipelines depend on it. Maybe someone else can offer better insight. As someone wanting to go into pipeline development, I am very curious.
Blender supports Python 3... time to move to blender I guess =P
Well, they still have arount 2.5 years of support (https://pythonclock.org/)
http://www.vfxplatform.com/
It's planned for 2019.
Nice! Thanks for pointing this out. This could be naive but maybe the script transition can be a hiring opportunity for those like myself... not that there are many of us.
Not a lot of text encoding going on there so most porting should be easy.
App engine still only supports python 2.7 in the standard environment...
It seems to support Python 3 (3.5.4): https://cloud.google.com/appengine/docs/flexible/python/runt...
Support exists at least since August 2016: https://cloudplatform.googleblog.com/2016/08/python-3-on-Goo...
Support exists at least since August 2016: https://cloudplatform.googleblog.com/2016/08/python-3-on-Goo...
Flexible environment only. This matters because the standard environment's pricing structure is a lot better for apps that go significant periods without much traffic, or that have spiky traffic patterns that necessitate fast scaling.
What prevents Google from offering Python3 support in standard environment? Is this a business decision?
It's on the roadmap and there's a public statement that it'll ship next year.
App engine is a niche environment.
Easy, easy! You're walking dangerous territories here. ;)
The story here is removing Python 2.7 support. This greatly simplifies the Django codebase. In terms of new features, it's relatively light, although I can see the new path-based urls being useful for new devs or those who are regular expression adverse.
I haven't tried it out yet, but I suspect dropping Python 2.7 is going to make tracebacks a whole lot clearer and easier to read. Right now, there tends to be a bunch of frames relating to `six`, which clutters things up.
The new path based URLs look great - to me, the gain looks like readability more than anything (reading regexps at a glance isn't exactly easy, especially if they have named groups), and having built in type coercion for the parameters is a nice win too.
The new path based URLs look great - to me, the gain looks like readability more than anything (reading regexps at a glance isn't exactly easy, especially if they have named groups), and having built in type coercion for the parameters is a nice win too.
> In terms of new features, it's relatively light
In a way that actually sounds like a good way to release things.
* Release 1.11 LTS with final feature updates for people who want to stay on Python2.7,
* Release 2.0 which is mostly a refactoring & internal cleanup - so for Django users on Python3 it should be a simple upgrade, and you get real life testing on it,
* Start adding features once the refactoring seems stable.
In a way that actually sounds like a good way to release things.
* Release 1.11 LTS with final feature updates for people who want to stay on Python2.7,
* Release 2.0 which is mostly a refactoring & internal cleanup - so for Django users on Python3 it should be a simple upgrade, and you get real life testing on it,
* Start adding features once the refactoring seems stable.
I'm hoping for a speed improvement here too. Regex compilation for the URLconfs adds about a second to our startup time which in development is quite a bit.
There's new `path()` as alternative to `url()` that allows one to use easier to remember syntax for url params like `<int:id>` instead of past `(?P<year>[0-9]{4})`. But if you need it, there's still `url()` for you to use power of regex in your urls.
And your shop still runs on Py2k, you'll need to move to Py3k to use Django 2.0. This also means that websockets support will not land on Django version that works for Py2k.
And your shop still runs on Py2k, you'll need to move to Py3k to use Django 2.0. This also means that websockets support will not land on Django version that works for Py2k.
How is <int:id> identical to (?P<year>[0-9]{4})? I'm talking about the {4}. Just an error in their blog post?
Does it support negative long integers?
EDIT: I am without actual internet or mobile tethering and an unable to `git clone https://github.com/django/django -b stable/2.0.x` and check out this convenient new feature.
EDIT: I am without actual internet or mobile tethering and an unable to `git clone https://github.com/django/django -b stable/2.0.x` and check out this convenient new feature.
It's still regex under the hood, the 'int' is just syntactic sugar for "[0-9]+":
https://github.com/django/django/blob/dda37675db0295baefef37...
https://github.com/django/django/blob/dda37675db0295baefef37...
Thanks!
Seriously? I mean you can achieve that with your own regex the old way. Surprised you’re asking the commenters here to investigate such a specific and odd use case of a convenience method.
You normally would want a three digit year to 404, and the same is true for a silly year like `3456` - you would 404 in the view. So, it isn't identical, but close enough for most purposes, as your view probably already has code to return 404.
I'd say the major things at the top of the release notes:
- Dropped support for Python 2
- New simpler syntax for specifying URL routes (as an alternative to the traditional regex-based one, which is still supported)
- The admin interface got a new responsive design that works better on mobile
- The ORM now has first-class support for OVER clauses
- Dropped support for Python 2
- New simpler syntax for specifying URL routes (as an alternative to the traditional regex-based one, which is still supported)
- The admin interface got a new responsive design that works better on mobile
- The ORM now has first-class support for OVER clauses
I wonder if they fixed the admin internals. When I looked (years ago), it had many sins, such as outputting markup in the the code.
You may want to read this:
https://jacobian.org/writing/so-you-want-a-new-admin/
https://jacobian.org/writing/so-you-want-a-new-admin/
I haven't used Django in a few years, but the relase notes look like only minor new features.
This isn't a huge change the world release which you might expect of a 2.0.
The biggest one seems to be dropping Python 2.x support. This is probably the reason for the 2.0.
This isn't a huge change the world release which you might expect of a 2.0.
The biggest one seems to be dropping Python 2.x support. This is probably the reason for the 2.0.
Correct. Starting with this release, Django is moving towards a model where every third release is semver-major. Every eight-month minor release will have new incremental features and deprecations. Each X.0 release will drop support for everything that was deprecated two or three releases ago, and each X.2 release will be an LTS release that gets bugfixes for the next 3 years.
Mostly minor changes, biggest developer facing changes involve dropping Python 2.x support and URL routing syntax (much more simplified, previously required a working knowledge of regex).
Besides dropping 2.0, the new urlconf syntax is a small but impactful improvement to something that you end up using very often.
It's a bit disappointing that Django doesn't emphasize REST more. I'm expecting that "classic" web application frameworks with templates rendered on the server (as long as they are not templates from a client-side framework rendered there for some optimization) are on their way out. And, to be honest, REST is not a strength of Django ...
Pretty sure client-side rendering will die first.
The whole JavaScript framework thing is just a stopgap until HTML standardization fixes all its weaknesses.
The whole JavaScript framework thing is just a stopgap until HTML standardization fixes all its weaknesses.
I started learning Django yesterday and now I'm not sure if I should just skip to the 2.0 alpha instead of learning the current stable version.
I wouldn't worry that much about it, the differences between Django 1.11 and Django 2.0 aren't major ones with the exception of dropping support for Python 2.x and the new simplified URL routing syntax.
Django 1.11 is a LTS (Long Term Support) release so it will have security upgrades until 2020, so you are safe sticking with it.
However I'd go ahead with 1.11 and transition to 2.0 to learn how Django handles deprecation and how to upgrade a codebase, both very useful skills as Django has a steady release process and it's often easier to track Django than to do a multi-version migration.
Django 1.11 is a LTS (Long Term Support) release so it will have security upgrades until 2020, so you are safe sticking with it.
However I'd go ahead with 1.11 and transition to 2.0 to learn how Django handles deprecation and how to upgrade a codebase, both very useful skills as Django has a steady release process and it's often easier to track Django than to do a multi-version migration.
I would go with the current version and be aware of the deprecated features in 2.0.
https://docs.djangoproject.com/en/dev/releases/2.0/?hnews#fe...
as long as you are using python 3, you shouldn't worry.
How a rails/ruby buy should start with python/django?
You don't.
Web framework these days are irrelevant IMHO. There are no land-sliding advantages between frameworks.
Pick up what you most familiar with, get job done ASAP.
Web framework these days are irrelevant IMHO. There are no land-sliding advantages between frameworks.
Pick up what you most familiar with, get job done ASAP.
I must agree with you. Between these 2 frameworks, even though they have their differences (and lots of them), they are mostly equivalent.
My recommendation these days goes like this: If you are more familiar or prefer Python use Django. If Ruby is your thing, go with rails.
Of course this rule has its own exceptions.
My recommendation these days goes like this: If you are more familiar or prefer Python use Django. If Ruby is your thing, go with rails.
Of course this rule has its own exceptions.
Disagree. Choose wisely, which means sometimes a FW you're not familiar with (but has some features that fit well with your problem/domain).
Like strong typing (Haskell), or actor model (Erlang/Elixir), or extreme speed/efficiency (compiled languages), or a "better JS" (Elm/PureScript/ReasomML).
> get job done ASAP.
But having maintainable/hackable/refactorable code is really nice too! IMHO, nowadays PhpWithFrameworkOfChoice+jQuery is not a very defendable choice for a greenfield "SPA".
Like strong typing (Haskell), or actor model (Erlang/Elixir), or extreme speed/efficiency (compiled languages), or a "better JS" (Elm/PureScript/ReasomML).
> get job done ASAP.
But having maintainable/hackable/refactorable code is really nice too! IMHO, nowadays PhpWithFrameworkOfChoice+jQuery is not a very defendable choice for a greenfield "SPA".
The tutorial on the Django.org site is quite excellent. You'll also want to learn a few important extensions, like django-extra-views and djcelery.
Django has a great ecosystem of addon packages covering all your needs:
Here's a nice grid of all these packages: https://djangopackages.org/
And a list of packages I use on (almost) all my projects:
* django-filter
* django-tables-2
* django-auth-ldap
* django-reversion
* django-compressor
* django-crispy-forms
* django-autocomplete-light
* django-extensions
* django-rq
* django-taggit
* django-rest-framework (if REST API is needed)
I always wanted to write a blog post about these packages but never have been able to find the time :/
Here's a nice grid of all these packages: https://djangopackages.org/
And a list of packages I use on (almost) all my projects:
* django-filter
* django-tables-2
* django-auth-ldap
* django-reversion
* django-compressor
* django-crispy-forms
* django-autocomplete-light
* django-extensions
* django-rq
* django-taggit
* django-rest-framework (if REST API is needed)
I always wanted to write a blog post about these packages but never have been able to find the time :/
> Previous versions of Celery required a separate library to work with Django, but since 3.1 this is no longer the case.
Source: http://docs.celeryproject.org/en/latest/django/first-steps-w...
Source: http://docs.celeryproject.org/en/latest/django/first-steps-w...
I've been impressed with all of the Django documentation.
The best way to get to a new scripting language/framework is by doing. In spanish we have a term for this: "Hacer camino al andar", which translates to "By walking you make a path".
Grab a small project(like a todo list), modify it and try to enhance it. I guarantee you will learn more from this than a thousand tutorials.
Grab a small project(like a todo list), modify it and try to enhance it. I guarantee you will learn more from this than a thousand tutorials.
Really nice tutorial is being made here:
https://simpleisbetterthancomplex.com/series/beginners-guide...
Author uses recent version of Python and Django and is building with You something useful.
Author uses recent version of Python and Django and is building with You something useful.
Two answers for you:
1) don't-- instead learn about making single page apps on the front end using React and Redux, or perhaps Angular 2. Then write a REST backend in either Node, Go, Python, or C#. Or go serverless and write the backend in Firebase.
2) if you really do want to do Django, start by doing the default tutorial that focuses on building something in the admin interface. Coming from a rails background you are on somewhat similar ground.
1) don't-- instead learn about making single page apps on the front end using React and Redux, or perhaps Angular 2. Then write a REST backend in either Node, Go, Python, or C#. Or go serverless and write the backend in Firebase.
2) if you really do want to do Django, start by doing the default tutorial that focuses on building something in the admin interface. Coming from a rails background you are on somewhat similar ground.
Answer 1) is plain wrong. I don't think that more than 10% of all web applications will benefit from SPAs. Your recommendation stands only for valley companies that have money to burn.
For example, in my industry (I work on the public sector) SPAs are never needed. Good old traditional request/response web apps, maybe with a little jquery on top to make things more responsive or add some advanced controls (autocompletes, keywords etc) are perfect for the job.
An experienced django developer can create a full traditional multi-user CRUD web app in a couple of hours. You'll just create the models and a couple of CBVs and everything else will be auto-created (but not magically created) through django-forms, django-filters and django-tables2. Now, how much time would you need to duplicate this functionality with an SPA? As I said, if you have money to burn then this is the way to go - on other cases, just use Django.
For example, in my industry (I work on the public sector) SPAs are never needed. Good old traditional request/response web apps, maybe with a little jquery on top to make things more responsive or add some advanced controls (autocompletes, keywords etc) are perfect for the job.
An experienced django developer can create a full traditional multi-user CRUD web app in a couple of hours. You'll just create the models and a couple of CBVs and everything else will be auto-created (but not magically created) through django-forms, django-filters and django-tables2. Now, how much time would you need to duplicate this functionality with an SPA? As I said, if you have money to burn then this is the way to go - on other cases, just use Django.
> Answer 1) is plain wrong. I don't think that more than 10% of all web applications will benefit from SPAs. Your recommendation stands only for valley companies that have money to burn.
Actually it's very easy to put together a single page application today! Really easy, really fast, really practical. I'll lay out the basic steps below. But before that, an important note: several years ago, what you said was totally true. In, say, 2013, it would have been a big piles-of-cash-burning exercise to make a single page application. Today, though, it's actually quite simple, fast, and productive to create and deploy a single page application. Here are the basic steps, assuming you're using Angular 2 for example.
1) Generate your application. This is a single command line command. 2) Edit it a little, add a text box and some buttons. 3) Deploy it to google app engine; this is a single command line command, too.
The time investment is in learning how to write apps with Angular 2 or React. That is indeed a big learning curve, but it's way easier today than it was years ago. Angular 2 is way easier to write apps in than Angular 1 was. Deployment is easier than it once was.
My real thesis here is that today is a good day to embrace the modern web and try things a new way-- single page apps are actually much more straightforward and practical than they were years ago.
I totally agree that if your goal is to build a crud app for a client then Django is likely a superior approach. But if you're already a Rails developer that wants to learn something new, then SPA is a better investment of time than Django.
Actually it's very easy to put together a single page application today! Really easy, really fast, really practical. I'll lay out the basic steps below. But before that, an important note: several years ago, what you said was totally true. In, say, 2013, it would have been a big piles-of-cash-burning exercise to make a single page application. Today, though, it's actually quite simple, fast, and productive to create and deploy a single page application. Here are the basic steps, assuming you're using Angular 2 for example.
1) Generate your application. This is a single command line command. 2) Edit it a little, add a text box and some buttons. 3) Deploy it to google app engine; this is a single command line command, too.
The time investment is in learning how to write apps with Angular 2 or React. That is indeed a big learning curve, but it's way easier today than it was years ago. Angular 2 is way easier to write apps in than Angular 1 was. Deployment is easier than it once was.
My real thesis here is that today is a good day to embrace the modern web and try things a new way-- single page apps are actually much more straightforward and practical than they were years ago.
I totally agree that if your goal is to build a crud app for a client then Django is likely a superior approach. But if you're already a Rails developer that wants to learn something new, then SPA is a better investment of time than Django.
> 1) Generate your application. This is a single command line command. 2) Edit it a little, add a text box and some buttons. 3) Deploy it to google app engine; this is a single command line command, too.
That will create a toy application. If you want to create a production application you need to handle data. To handle data you will need:
* Tables / lists to display the data
* Views to edit and display the data
* Forms to edit the data
* Auditing of the user actions
* User authentication + authorization
All these are not trivial to create in an SPA especially since you'll always need both server and client side code. With django (or rails, or spring or various other server only frameworks) you won't need to write client code and most of these components will be auto-generated (at leas their default values).
For your last comment, I also agree that if you know rails then you don't really need to learn django since they are both similar (however I do profer django because of its no magic philisophy and because python is a better language than ruby) but I believe that you also don't need to go the SPA route until somebody specifically asks for an SPA and has good reasons asking for it (or you want to learn the technology and modern frameworks that surround SPAs).
As a final comment, I have to say that really like all those modern frameworks (especiall react and redux) but I won't consider them for my day-to-day job since instead of creating something in 1 week I'd need 1 month using these technologies.
That will create a toy application. If you want to create a production application you need to handle data. To handle data you will need:
* Tables / lists to display the data
* Views to edit and display the data
* Forms to edit the data
* Auditing of the user actions
* User authentication + authorization
All these are not trivial to create in an SPA especially since you'll always need both server and client side code. With django (or rails, or spring or various other server only frameworks) you won't need to write client code and most of these components will be auto-generated (at leas their default values).
For your last comment, I also agree that if you know rails then you don't really need to learn django since they are both similar (however I do profer django because of its no magic philisophy and because python is a better language than ruby) but I believe that you also don't need to go the SPA route until somebody specifically asks for an SPA and has good reasons asking for it (or you want to learn the technology and modern frameworks that surround SPAs).
As a final comment, I have to say that really like all those modern frameworks (especiall react and redux) but I won't consider them for my day-to-day job since instead of creating something in 1 week I'd need 1 month using these technologies.
I think you and I are actually not far apart on this at all. Everything you mentioned Django does well. And so does Rails. And I sorely miss the beauty of Django admin in the world of SPA's.
I agree and disagree. I think API first and some form of a SPA is insanely powerful and probably the way to go for most larger scale projects. For everything else there is a lot of things that can be solved from a simple templating system. Sure its not as sexy but for a lot of the business cases you really don't need a sexy interface.
My favorite example is the bloatware that is Asana. I would be 10x happier if it was a using simple components written in JS but not the whole app hiding inside of a bloated SPA.
My favorite example is the bloatware that is Asana. I would be 10x happier if it was a using simple components written in JS but not the whole app hiding inside of a bloated SPA.
Where do you draw the line on larger scale projects? Also how do you handle optimistic updates for things like drag and drop?
1) -> Yeah sure. Without knowing what the project is about, this approach will surely cover all bases. /s
I've already put about 10x the effort (based on character count) into answering the question than the person put into asking it. I wasn't actually attempting to cover all the bases; that'd be a few books and blog articles.
If the goal is to learn Django, then the basic tutorial is a great place to start, especially for a Rails engineer. If the goal is to build something from scratch in 2017, Django is probably not good choice for someone that's already a Rails expert.
Django would be a great way to set up an admin interface and rapidly get a CRUD interface going for an app of 20+ inter-related tables going. But the OP is already a Rails engineer, and in the modern world they're not going to be gaining much. Django is indeed a nice way to make REST backends, but so is Rails.
If the idea is to learn something new for an existing Rails engineer, then single page apps are a good choice or some other way to make backends (such as Flask) would be a superior investment of time.
If the goal is to learn Django, then the basic tutorial is a great place to start, especially for a Rails engineer. If the goal is to build something from scratch in 2017, Django is probably not good choice for someone that's already a Rails expert.
Django would be a great way to set up an admin interface and rapidly get a CRUD interface going for an app of 20+ inter-related tables going. But the OP is already a Rails engineer, and in the modern world they're not going to be gaining much. Django is indeed a nice way to make REST backends, but so is Rails.
If the idea is to learn something new for an existing Rails engineer, then single page apps are a good choice or some other way to make backends (such as Flask) would be a superior investment of time.
Django is an excellent choice for writing a REST backend though.
It definitely can be, but for myself I find it easier to use Flask for that particular case.
How smooth is to upgrade your app to every future release of Django? Starter here, on Python and then Django.
In very broad terms it's not bad. The docs are great and they give specific advice for upgrades.
With that said you may find many 3rd party apps / utils lagging. A couple libs I use still don't support new style middleware, for instance.
With 2.0 dropping support for py2.7 this might cause more pain points for poorly maintained libs but all in all keeping up with Django releases is pretty straightforward and almost always worth it.
Source: happily using Django since 2008.
With that said you may find many 3rd party apps / utils lagging. A couple libs I use still don't support new style middleware, for instance.
With 2.0 dropping support for py2.7 this might cause more pain points for poorly maintained libs but all in all keeping up with Django releases is pretty straightforward and almost always worth it.
Source: happily using Django since 2008.
Ditto leetrout: upgrading Django itself is easy, with great release notes, deprecation warnings, and long support windows for old versions.
We always end up with a bunch of third party libraries, though, and those end up being upgrade blockers.
A notable example recently was django-tastypie, which didn't cut a Django 1.10-compatible release for 11 months after it came out -- four months after Django 1.9 lost security support. So part of our Django 1.10 upgrade was moving to another REST framework.
(If you don't want that kind of churn, sticking to LTS would make sense - I think 1.8 still has support.)
We always end up with a bunch of third party libraries, though, and those end up being upgrade blockers.
A notable example recently was django-tastypie, which didn't cut a Django 1.10-compatible release for 11 months after it came out -- four months after Django 1.9 lost security support. So part of our Django 1.10 upgrade was moving to another REST framework.
(If you don't want that kind of churn, sticking to LTS would make sense - I think 1.8 still has support.)
If you stick to LTS releases, you are guaranteed to be able to upgrade from one LTS to the next without breaking changes. There will only be deprecation warnings about the next LTS release.
So basically nothing new.
Nothing about channels, ASGI or any async support which IMHO are way overdue to be included.
Hmm, I haven't done much with Django in a while, but for a major version this seems a bit... underwhelming.
Dropping python2 is a pretty big feature alone.