I can't wait to check it out more.
On a sidenote, I feel bad for the developers who have to migrate to Django 2.0. Hopefully it's not too much work, I know a codebase review and full update can't be fun with the business managers and customers at your throat.
If your code was emitting deprecation warnings, then you have to fix them before upgrading, but this should be relatively rare and they shouldn't be that hard to fix.
If you're still on Python 2, then you have to either migrate to Python 3 or stay on Django 1.11 (which is an LTS release). 1.11 EOL is April 2020, which is the same time as Python 2's EOL, so you were going to have to migrate your codebase by then anyway.
That's an optimistic viewpoint.
If you need to upgrade from Python 2 to Python 3 it will likely be a fair amount of work.
In case it's useful, here's what I did to upgrade my blog (a pretty simple application, though one that's been around for a long time and survived a lot of different Django versions): https://github.com/simonw/simonwillisonblog/pull/10
Django only has one paid full-time maintainer to my knowledge (Tim Graham). So given the team's limited peoplepower Only the last two releases (+LTS releases) get security updates. This means that Django 1.10 (released 18 months ago) won't get updates, so if you use any new features you're on the upgrade treadmill.
Django itself is very good about offering clean upgrade paths. Very vocal about breakage, usually will not introduce breakage unless there's some good reasons to. Unfortunately third party libraries often take a while to update, so you can quickly find yourself overwhelmed with figuring out which deps are safe to upgrade and which aren't.
I try to be a good OSS citizen and send in compatibility fixes for libraries that fall behind, but maintenance can be hard when you're only really using about 25% of a library.
I wouldn't be comfortable with sticking to older Django LTS releases (there was still a lot of obvious improving to be had in the ORM and migrations in particular), but I think Django 2.0 is in an amazingly good place now. Sticking to this for a couple years would be fine for a lot of people.
It indeed does, but I don't agree that it is too limiting in that respect. A lot of Tim's time is spent curating, reviewing and merging PR's contributed by the community. It's far, far from a one-man band.
Not sure if that was what you are implying, but that's how I read it.
Garanty of compatibility between Django and ALL my external packages is a lot more valuable that a responsive admin panel and a new syntax for urls.
I would love "important" (yeah it's opiniated) packages move to the official Django repo (like Channels), to help reduce this risk when migrating. It's actually surprising how often I can't find the compatibility information of a Django package.
I would love to see someone start on a combination of `pyup` and some "maintenance fee" for projects that are found in ones `requirements.txt`.
For a monthly fee you can make sure that at least someone is checking to see that your Django dependencies are being kept up to date as time moves forward. The pitch being "get an extra maintenance developer for a fraction of the cost".
Though, in theory, I don't think there's any actual difference in support having it under the Django _organization_.
Source: before we hired Tim, I was doing most of the releases.
Stability is very important too.
If you don't receive warnings, your code will work fine on future 2.x releases.