The point is that instead of the upstream developers doing their job and maintaining backwards compatibility or providing automated migration scripts, tens of thousands of downstream developers will waste tens of thousands of hours fixing that intentional breakage.
That's why a new Django major/minor version is never a good news, but a periodic reminder of how broken the ecosystem is.
Those features were marked to be deprecated 2 major releases ago (2 years ago), per their deprecation policy. At some point features or behavior will need to be deprecated so the framework can move forward. That doesn't sound broken at all to me...
Broken by design is leaving data corrupting bugs in the framework when a fix exists, just to preserve "working" code.
Granted, there are still a lot of backwards incompatible changes that aren't so severe. But every single change that is backwards incompatible is scrutinised, and only makes the cut if the deemed benefits outweigh the projected costs. If the costs aren't worth it to you or your client, then hang around on 1.7 until it goes out of support.
I'm looking (..and have contributed to) the list of backward incompatible changes in 1.8 and, frankly, there isn't a whole lot there that will cause the majority of users any pain. There is a big list you have to analyse, yes, but there shouldn't be a lot of work to bump versions.
Frameworks evolve. If they don't, they crumble under their own weight and die, and then no one is using them anyway. Most people are fairly reasonable with regards to upgrades and changes.
Are you happy with any of the features that are landing in 1.8? Because chances are that at least some of those incompatible changes are required for that feature to work or that bug you hated to get fixed.
Maybe you can elaborate why this is supposed to be "broken by design"? Django's deprecation policy is one of the best, and also older versions receive (security) updates for a long time.
If you're not content with the functionality provided by an open source software there's still much room left to take actively part in its development.
> If you're not content with the functionality provided by an open source software there's still much room left to take actively part in its development.
> Maybe you can elaborate why this is supposed to be "broken by design"?
Imagine the glibc fork() function changing its return value in the child process. The change is announced through an excellent deprecation policy that guarantees system wide breakage every month. Would that be acceptable?
Right. Volunteer work on an open source project is a giant conspiracy to blackmail you into contracting for a commercial support contract. The beneficiaries, of course, are the dark cabal of Caktus, RevSys, Lincoln Loop, slashRoot, 791 tech, and so on.
Behemoths all, and existential threats to your clients without exception.
You are correct that cornering people as conspiracy nuts is not a proper response and, in the presence of a fact pattern of tenuous certain, is a logical fallacy.
However, in this case, you've implied, at least enough to set off my detector of hostility, that all of us that work on Django are engaged in a plot to force you to pay for fancy expensive service contracts.
This is simply crazy on its face. I hardly commit to Django core at all, but when I do, I do so with an intent to make the world a better place - and I say that unironically. I am psyched for the capacity of Django and frameworks like it to make communication and archival of the human condition ever more accessible and powerful.
Do you know how intensely Andrew, Carl, Russell, Jannis, and Aymeric (the 1.8 technical team) work on Django? It's a full-on lifestyle choice. I'm so happy to have the privilege of watching them work, let alone using their product, that I simply cannot imagine the kind of cruelty it must take to accuse them of not working hard enough to ensure that your clients are happy.
We all have clients. If yours aren't sufficiently happy with Django 1.8 (or 1.9 - already time to get going on it), then get your ass over to github and fix whatever's bugging you.
If it's seriously reverse incompatibility with features that have had deprecation warnings for TWO YEARS now, then I want to suggest that you need to zoom out your perspective a little. How many companies do you know that were on PHP frameworks two years ago and have happily switched to Django? Better yet, closed-source CMS systems?
I respect that you have a dissenting opinion, and I really hope you do outline more of your position. But don't you dare cast these people who bust their ass for you - for free - as villains of some sinister plot to bilk all the people who didn't read the deprecation warnings.
I am glad I am not your client.
You are upset at an open source project because it makes new versions and progresses?
Sigh - this is why we need an engineering style qualification before we let all these blaggers run around crapping out software, hurting their clients, and calling themselves developers!
I think parent is way out of line, but are you serious? Are you suggesting that keeping people on 1.4, which is slated to stop receiving security upgrades in October, is anything but reckless?
it is just me or is this a bigger release than normal? Great job to the Django team, this is more proof that Django is the defacto choice when building web applications in Python.
Flask is good, but Django comes with many more batteries included, which all major websites need.
I used Django a few years ago but am now learning Flask and coupled with SQLAlchemy, WTForms and a few other extensions seems to be very intuitive and powerful.
Just curious, what batteries in Django make it preferable to you over Flask+SQLAlchemy+Jinja2?
Not so much included, it's more like the battery slot that the Django template language fits in is now easily accessible. So you can change your "Duracell" [Django Template Language] for "Energizer" [Jinja2].
But it's a pretty great change as there are legitimate times that Jinja2 is worth using over the Django system.
I learnt Flask first and then Django. I like Django more. Figuring out which Flask package to pick is lot of unnecessary work. In most cases, you would end up using templates, ORM, Security, Forms, Admin, Migration anyway. Django's defaults for these (now including Jinja2 with this release!) are quite good.
Also I found SQLAlchemy tooo complicated. Too much to learn there. It might be really cool for edge cases, but I'm happy using raw SQL when/if the Django ORM (ever) falls short of my needs.
Also performance benchmarks seem to suggest that Django is faster than Flask. This was a surprise to me. As in, it seems as if Flask is leaner so would be faster, but Django performs better than flask. Also, I kinda like the Django community more.
I think this has been my biggest annoyance with Flask to date. Searching Google/SO on issues I run into provide far fewer results (and often none that directly answer my question) than Django.
Still probably think Flask is worth learning first though as it gets you closer to the Python core and hoping if I switch back to Django the transition will be easy enough.
I make part of my living from Django work. I like Flask a lot more. It feels a lot less boilerplate-y, eg for routing, views etc. One of Flask's strongest points though is Jinja2 IMO and Django getting that is fantastic news.
I couldn't agree more on SQLAlchemy, though. Django's orm is nasty perf-wise and if you want to do anything low level, but API-wise it's really great. But SQLAlchemy felt like learning something even more complex than SQL itself... It's weird this isn't a solved problem.
SQLAlchemy core basically is raw SQL in Python syntax, but better - it's composable, whereas plain SQL isn't. SQLAlchemy declarative looks similar to Django's models, except it was designed from the ground up to handle multiple transactions and DB connections, which isn't necessarily true for Django's ORM. I wouldn't be afraid to say that SQLAlchemy is a state-of-the-art tool in ORM space (not only Python ORM space). Flask-SQLAlchemy extension adds some niceties that make it look even more similar to Django's framework.
Jinja2, the results of the postgres kickstarter coming in, DurationField/UUIDField, integration of django-secure... this release is massive, almost bigger than 1.7.
1.7 has migrations (huge), app loading refactor (big), system check framework (big, but relatively internal), and custom lookups API (cool, but not fully utilised yet). Most of the other features were smaller niceties.
1.8 has public Meta, multiple template engines, contrib.postgres, and query expressions (my pet). Again, most other features were smaller nice to haves.
I'd say the features of both are relatively on-par. Migrations probably give a false sense of scale just because that one feature was so big.
As for the "new normal" comment, I agree with you. I'm not sure there are many big bang features ready to go or that have been proposed. I think 1.9 will see lots of incremental improvements and bug fixes.
This release is going to be huge. With support for Postgres arrays, UUIDs, security checks, jinja2, better fixtures support, etc., the gap between professionals and amateurs is getting smaller and smaller.
I remember five years ago when you could make enormous amounts of money if you knew how to send a tweet, ten years ago when you could make enormous amounts of money if you knew how to install anti-virus software, etc. And now these things have gotten so easy that the value of knowing how to do them is basically zero. Releases like this show that web development is quickly going the same way.
I would add though, the one thing I'm hoping to see in an upcoming release is native support for JWT auth. Right now it's annoying to have to add Rest Framework just to be able to follow current best practices for having an API-driven front end, assuming you don't also have a need to serialize your endpoints into YAML or whatever.
I remember five years ago when you could make enormous amounts of money if you knew how to send a tweet...
I don't. Wow, what a missed opportunity.
ten years ago when you could make enormous amounts of money if you knew how to install anti-virus software
I don't remember that, either. That said, you can still make passable money doing charlatan "computer repair" that amounts to running an antivirus scan, CCleaner, disk cleanup and maybe some graphics tweaks to speed things up a bit.
And now these things have gotten so easy that the value of knowing how to do them is basically zero.
They've always been easy?
Releases like this show that web development is quickly going the same way.
It's an arms race, really. You have a lot more batteries than ever before, but the expectations for today's web applications are so high that the real value comes in being able to compose vast and multifaceted technological stacks, which as it turns out, is not so easy. There's almost this zealotry against building a native application that makes people take ridiculous hoops just so they can view things under a web browser.
Additionally, the abstractions are still pretty leaky thus far, so building a complex app requires a lot of domain-specific knowledge that has yet to become invisible.
> I remember five years ago when you could make enormous amounts of money if you knew how to send a tweet
What? Do you mean programatically send a tweet based on some event? I think you can still make money from that.
> ten years ago when you could make enormous amounts of money if you knew how to install anti-virus software
Still don't know what you're talking about. While the demography that had difficulty installing anti-virus on their windows box 10 years ago, now get a bare-bones anti-virus bundled with windows 8 -- this same demographic still need help with a lot of the same things they needed help with 10 years ago. So I'm not quite sure what you think have changed?
Just as a tip, it might be easier to do a progressive upgrade, i.e. move to 1.5 -> 1.6 -> 1.7 -> 1.8 on older code bases. This way you will get deprecation warning, instead of failure. IIRC Django moves from deprecation to removal in two releases.
On a side note, it is also a good time to try out Python 3, as most packages now support both 2 and 3.
Django 1.5 is no longer supported (even for security patches), 1.6 will only receive security and data loss bug fixes after 1.8 is released, and (IMHO) upgrading from 1.4 to 1.6 (or esp 1.7) is almost as difficult and time consuming as just going straight to 1.8, whereas upgrading from 1.4 to 1.5 was a breeze.
Python 3 is wonderful to work with now, compared to just a year ago. Django's support for Python 3 really helped speed up the ultra-slow process of getting many of the popular libraries to support it. IOW, now is a great time to start using Python 3 for new projects.
I'm in the middle of this process, but from an even older version.
Since 1.7 introduced migrations, I recommend upgrading to 1.6 first and getting your South migrations caught up with third party apps. Some may have data and schema migrations e.g. django-photologue. Then jump to 1.7 or 1.8.
You'll likely have to update your requirements.txt with the latest packages, so you'll want to see if they're compatible with the version you're upgrading to.
I recommend keeping it up-to-date with every release if possible. Much easier to make incremental updates than spend months on upgrading 4 major versions.
See my comment above, pertaining supported versions, etc.
Do try out migrations in 1.8, btw. When Andrew Godwin migrated them into Django, a lot of things were changed, and now migrations are truly great to work with.
Django has a `CachedStaticFilesStorage` storage class that you can use to store the MD5 hashed names of your processed files [1]. I use that with django-storages to store my files in S3/Cloudfront [2].
No, there won't be. If you upgrade to 1.5, then 1.6, then 1.7, then 1.8 using the release notes from each version, that's your best bet. Any guide moving from LTS to LTS would just be a copy paste job between incremental versions anyway.
Wow, release notes look great. I'm so impressed with the whole Django ecosystem - I'm yet to find a problem without a good answer on SO, there's a package for most of the repetitive stuff when building a web app. I tried to follow the development process on GitHub for some time and while it was a valuable experience [1], it can be like a side project on its own, just to keep up with all the issues and bigger commits.
Anyway, I'm incredibly thankful for all the contributors. Learning and using Django let me meet great people, experience new things and had quite an impact on my life. Yay Open Source! ;).
[1] In general, I think that watching big project on GitHub for just a few weeks can be better lesson than reading a book on the topic (it depends, of course, but it's a great learning experience nonetheless)
52 comments
[ 4.4 ms ] story [ 96.6 ms ] threadThat's why a new Django major/minor version is never a good news, but a periodic reminder of how broken the ecosystem is.
Granted, there are still a lot of backwards incompatible changes that aren't so severe. But every single change that is backwards incompatible is scrutinised, and only makes the cut if the deemed benefits outweigh the projected costs. If the costs aren't worth it to you or your client, then hang around on 1.7 until it goes out of support.
I'm looking (..and have contributed to) the list of backward incompatible changes in 1.8 and, frankly, there isn't a whole lot there that will cause the majority of users any pain. There is a big list you have to analyse, yes, but there shouldn't be a lot of work to bump versions.
Frameworks evolve. If they don't, they crumble under their own weight and die, and then no one is using them anyway. Most people are fairly reasonable with regards to upgrades and changes.
Are you happy with any of the features that are landing in 1.8? Because chances are that at least some of those incompatible changes are required for that feature to work or that bug you hated to get fixed.
I tried and it was a complete waste of my time: https://code.djangoproject.com/ticket/18494
> Maybe you can elaborate why this is supposed to be "broken by design"?
Imagine the glibc fork() function changing its return value in the child process. The change is announced through an excellent deprecation policy that guarantees system wide breakage every month. Would that be acceptable?
Behemoths all, and existential threats to your clients without exception.
However, in this case, you've implied, at least enough to set off my detector of hostility, that all of us that work on Django are engaged in a plot to force you to pay for fancy expensive service contracts.
This is simply crazy on its face. I hardly commit to Django core at all, but when I do, I do so with an intent to make the world a better place - and I say that unironically. I am psyched for the capacity of Django and frameworks like it to make communication and archival of the human condition ever more accessible and powerful.
Do you know how intensely Andrew, Carl, Russell, Jannis, and Aymeric (the 1.8 technical team) work on Django? It's a full-on lifestyle choice. I'm so happy to have the privilege of watching them work, let alone using their product, that I simply cannot imagine the kind of cruelty it must take to accuse them of not working hard enough to ensure that your clients are happy.
We all have clients. If yours aren't sufficiently happy with Django 1.8 (or 1.9 - already time to get going on it), then get your ass over to github and fix whatever's bugging you.
If it's seriously reverse incompatibility with features that have had deprecation warnings for TWO YEARS now, then I want to suggest that you need to zoom out your perspective a little. How many companies do you know that were on PHP frameworks two years ago and have happily switched to Django? Better yet, closed-source CMS systems?
I respect that you have a dissenting opinion, and I really hope you do outline more of your position. But don't you dare cast these people who bust their ass for you - for free - as villains of some sinister plot to bilk all the people who didn't read the deprecation warnings.
Still sounds good.
Flask is good, but Django comes with many more batteries included, which all major websites need.
Just curious, what batteries in Django make it preferable to you over Flask+SQLAlchemy+Jinja2?
But it's a pretty great change as there are legitimate times that Jinja2 is worth using over the Django system.
Also I found SQLAlchemy tooo complicated. Too much to learn there. It might be really cool for edge cases, but I'm happy using raw SQL when/if the Django ORM (ever) falls short of my needs.
Also performance benchmarks seem to suggest that Django is faster than Flask. This was a surprise to me. As in, it seems as if Flask is leaner so would be faster, but Django performs better than flask. Also, I kinda like the Django community more.
rest api's (no out of the box support but plenty of documentation to make your own or just go with Django-rest-framework)
Built in administration system/back end.
easy cache plugins, middleware extensions,
GIS support with Geo-Django
Still probably think Flask is worth learning first though as it gets you closer to the Python core and hoping if I switch back to Django the transition will be easy enough.
I couldn't agree more on SQLAlchemy, though. Django's orm is nasty perf-wise and if you want to do anything low level, but API-wise it's really great. But SQLAlchemy felt like learning something even more complex than SQL itself... It's weird this isn't a solved problem.
Django 1.7 was just huge; this is more in line with the changes in 1.5 and 1.6.
1.8 has public Meta, multiple template engines, contrib.postgres, and query expressions (my pet). Again, most other features were smaller nice to haves.
I'd say the features of both are relatively on-par. Migrations probably give a false sense of scale just because that one feature was so big.
As for the "new normal" comment, I agree with you. I'm not sure there are many big bang features ready to go or that have been proposed. I think 1.9 will see lots of incremental improvements and bug fixes.
I remember five years ago when you could make enormous amounts of money if you knew how to send a tweet, ten years ago when you could make enormous amounts of money if you knew how to install anti-virus software, etc. And now these things have gotten so easy that the value of knowing how to do them is basically zero. Releases like this show that web development is quickly going the same way.
I would add though, the one thing I'm hoping to see in an upcoming release is native support for JWT auth. Right now it's annoying to have to add Rest Framework just to be able to follow current best practices for having an API-driven front end, assuming you don't also have a need to serialize your endpoints into YAML or whatever.
I don't. Wow, what a missed opportunity.
ten years ago when you could make enormous amounts of money if you knew how to install anti-virus software
I don't remember that, either. That said, you can still make passable money doing charlatan "computer repair" that amounts to running an antivirus scan, CCleaner, disk cleanup and maybe some graphics tweaks to speed things up a bit.
And now these things have gotten so easy that the value of knowing how to do them is basically zero.
They've always been easy?
Releases like this show that web development is quickly going the same way.
It's an arms race, really. You have a lot more batteries than ever before, but the expectations for today's web applications are so high that the real value comes in being able to compose vast and multifaceted technological stacks, which as it turns out, is not so easy. There's almost this zealotry against building a native application that makes people take ridiculous hoops just so they can view things under a web browser.
Additionally, the abstractions are still pretty leaky thus far, so building a complex app requires a lot of domain-specific knowledge that has yet to become invisible.
Have they gotten easier...or have you, yourself, gained more experience and knowledge that you understand things better now?
I guess you are meaning Django is not a professional framework?
What? Do you mean programatically send a tweet based on some event? I think you can still make money from that.
> ten years ago when you could make enormous amounts of money if you knew how to install anti-virus software
Still don't know what you're talking about. While the demography that had difficulty installing anti-virus on their windows box 10 years ago, now get a bare-bones anti-virus bundled with windows 8 -- this same demographic still need help with a lot of the same things they needed help with 10 years ago. So I'm not quite sure what you think have changed?
On a side note, it is also a good time to try out Python 3, as most packages now support both 2 and 3.
Python 3 is wonderful to work with now, compared to just a year ago. Django's support for Python 3 really helped speed up the ultra-slow process of getting many of the popular libraries to support it. IOW, now is a great time to start using Python 3 for new projects.
Since 1.7 introduced migrations, I recommend upgrading to 1.6 first and getting your South migrations caught up with third party apps. Some may have data and schema migrations e.g. django-photologue. Then jump to 1.7 or 1.8.
You'll likely have to update your requirements.txt with the latest packages, so you'll want to see if they're compatible with the version you're upgrading to.
I recommend keeping it up-to-date with every release if possible. Much easier to make incremental updates than spend months on upgrading 4 major versions.
And read ALL the release notes.
Do try out migrations in 1.8, btw. When Andrew Godwin migrated them into Django, a lot of things were changed, and now migrations are truly great to work with.
[1] https://docs.djangoproject.com/en/1.7/ref/contrib/staticfile... [2] https://mike.tig.as/blog/2011/12/22/django-14-first-thoughts...
Anyway, I'm incredibly thankful for all the contributors. Learning and using Django let me meet great people, experience new things and had quite an impact on my life. Yay Open Source! ;).
[1] In general, I think that watching big project on GitHub for just a few weeks can be better lesson than reading a book on the topic (it depends, of course, but it's a great learning experience nonetheless)