Django 1.10 released | Hacker News Reader

Django 1.10 released

djangoproject.com

227 pointshrayr119 comments

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/

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.

Channels will get there. It just wasn't quite ready on time for 1.10. Hopefully it will be ready on time for 1.11, and then it'll ship in Django.

I just used Channels in a personal project and it's great! My requirements were mostly basic and I haven't put it into production yet, but everything has gone smoothly so far.

What did you do with it? I still haven't figured out what to do with them...

I made something like a cross between a chat room and reddit. There are any number of possible rooms (like subreddits), with new top level posts popping up in real time, and when you click on a post, it expands and the replies become visible as a comment chain. It's not done yet though. For a while now I've been trying to do as much as I can on a single project for one week, and then start another. I definitely plan to come back to this one when I can.

This week I'm using Channels again too. I'm making a head-to-head Minesweeper web app where you can challenge and compete against other players. After finding an opponent, essentially you'll see your own board and your opponent's board side by side, and each players' progress is broadcast in real time via Channels to one another.

Cool games and chat both seem like obvious uses.

Why did the ORM suck before? Were there major changes done to the ORM?

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/

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.

The built-in migration code is even the continuation of South.

https://www.kickstarter.com/projects/andrewgodwin/schema-mig...

sibling mentioned ORM migrations not being built in.

It used to be that it was very hard to write custom expressions or aggregations (like `SUM`) in a way that would be first-class with ORM-provided expressions. This has been massively improved, and been made into a public API. So if the ORM doesn't support something you can write it easily.

The core has also been majorly rewritten, which has made entire classes of bugs disappear. Before 1.8, it was possible to write expressions where the filters got so complex that the ORM would just give up.

The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare.

This doesn't happen anymore.

A lot of old Django core code isn't really super durable, and you get a lot of pain because of it. But the past couple of releases have cleaned up a lot of code, making Django into an extremely clean project.

> The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare.

Is this really true? Can you point me at any tickets or examples? Everything else you've said is bang on though.

Ah, I feel bad, because I ran into this twice and didn't report this properly. The situations I ran into happened whenever I would combine filters and excludes, along with some joins. The system would simply drop filters, and just do a plain SELECT on the table. But ever since the 1.8 ORM update, I have no longer been able to reproduce this, so have assumed it was fixed through cleaning up the internals.

I did report a related bug[0] where the ORM gets confused by complex queries, but it didn't just drop the filter. It blew up, which is better but still a bit concerning.

[0]: https://code.djangoproject.com/ticket/24386

Exclude filters are awful and very unintuitive if you know SQL in my experience. I'd much prefer to use negated filters like: `.filter(id__notequal=3)`. I'm giving a talk at djangocon AU in a couple of weeks where I'll step through examples like this.

Right. Worse case, you can use `~Q` or the like. The way I recall it, this didn't solve the issue (as in: something more fundamental than "using exclude instead of filter"), but I no longer have the example...

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?

That is true, but it was fixed in Django 1.4... in 2012. Technology moves a bit in 4 years.

Yep, but as I said it's still rather limited compared to SQLAlchemy. Stuff like aggregations are cumbersome, and it's really really easy to shoot yourself in the foot and cause O(n) queries (especially in templates and in custom admin views).

Things specific to Postgres are rather lacking. While they added support for advanced datatypes like arrays, hstore, intervals and search recently (yay!) you still can't use any other index than a standard btree one or things like recursive queries. SQLAlchemy supports all of these, and has done since forever.

Things are progressing, don't get me wrong, but there is a long way to go.

SQLAlchemy has a lot more power than Django's ORM. I'd argue that Django's ORM is more accessible to beginner SQL users though. Django handles joins for you (which admittedly breaks down with very complex queries) which is the only ORM I'm aware of that does. SQLAlchemy maps much more closely to SQL and is a tighter abstraction.

A GSOC project is currently adding customisable indexes: https://groups.google.com/forum/#!topic/django-developers/XA...

Why a shame? What would Channels buy you if it were included into the framework?

I would love to see Django split up into smaller official external packages and repackaged as two or three different official starter packs (Traditional, API, SPA, etc.) with each containing a different set of packages that make sense (DRF, Channels, Models, Views, Forms, etc.).

I know this goes against the current "Batteries are included" model, but why can't we treat Django as the standards body, and the various starter packs as the more targeted "batteries are included" frameworks.

You might as well use Flask at that point. You can use cookie-cutter to create the starter packs.

Sure, I love Flask but Django has it's own ecosystem and that's what I'm talking about. I know anyone can use cookie-cutter, but I'm talking about trimming Django itself. Externalize Forms, Templates, etc. and build several core starter packages (including current Django). This gives a few base starting points.

There are two benefits to having subpackages in the way you describe. The first, as you mention, is to slim down the framework. I don't think this gains a whole lot except for trimming down deployment sizes. If you don't use the components then the code doesn't run.

The other benefit would be so that the components could be used outside of Django. Using forms or templates might appeal to projects outside of Django. This isn't currently possible for a large majority of components since they depend on the global settings module, and/or other components.

What could be done with the dependency constraints is to build in different templates that `startproject` would create for you. It'd only be able to modify settings and write out requirements files, but it'd achieve a structure for different app types.

DJango 1.10 source download is 7MB.

I don't know what is normal for Ruby. Basic crud app in Java tends to be 20-50MB, but DJango above doesn't have DB drivers or anything yet so I suspect it is similar.

*seems reasonable.

I love Flask. People say Django is easier to use but I had a much easier time with Flask. It's well documented and very flexible.

Maybe not easier to use in general, but you don't have to replicate all the daily stuff you maybe need for your project. With Flask you have to recreate many things (for example acc management) or rely on a thrid party-dev. In django you get core stuff from the core team(also with the freedom of recreating it yourself or use some app from a thridparty-dev).

I think most Django developers would love to use their toolkit elsewhere (eg the ORM) but in practice, everything it held together by so much Django glue (setting and convention) that I don't see how it would be practical.

By that point you may as well just import Django, bootstrap it and use what you need.

The other side of this argument, is you allow each component to be developed at its own speed. Again, the integration between elements (Models→ModelForm→Forms etc) is so tight this isn't practical. Just as making them less integrated [probably] makes them harder to use for people who just want to use Django.

Django isn't that big in terms of file size, and you can just turn off the batteries you don't need.

So does that mean we should pick a new language/framework that is "hot" now and write a bunch of libraries for it? Basically, reinventing the wheel over and over and over again?

There are some differences that one could call objectively better in other technologies compared to Python/Django.

I'm somewhat conflicted about Channels. On the one hand it's cool what you can do with it and the design cleverly avoids rewriting all of Django to be async. On the other hand it is crazy how many shenanigans one needs to pull off to achieve what comes for free with Go or Erlang.

Fashion-like churn is obviously nonsense and reinventing the wheel usually a waste of time. But when you need a really round wheel and your current tools can only make hexagons...

Huh. Your argument in favor of Django is basically "it may not be cool, but it's got a lot of libraries written for it." Which is basically the same thing people used to say (and still say) about Java, compared to something "cool" and "new" like, say, Django or Rails (at the time). In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.

Was Django ever the hot new thing? Python certainly isn't and has never been "hot."

In the 2000s, it seems much more like all the attention went to RoR. Now all the attention goes to JavaScript.

In the meantime, Django has steadily added new functionality while adhering to smart core principles. It really does seem to be in the sweet spot of dependability and convenience. I don't think anything else is faster to develop with.

You must have been asleep 5-10 years ago when Rails and Django were repeatedly being pitched against each other by hipster developers, leaving PHP, looking for the "new thing".

They were both scorching hot until somebody decided doing everything in Javascript was a good idea.

(Edit FTR: Given the topic thread, I feel it important to say that I didn't mean Node et al are better than Django, just that these hipsters thought —by virtue of being newer and newer is always better— it time to move on. I'm a Django dev and judging by the positive state of development, will be for a LONG time.)

I guess I remember all the hype going to Rails, not Django. For example, dozens of coding bootcamps used a Rails curriculum but I haven't heard of a single one which taught Django.

>* In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.*

Yeah, in other words, it's now both mature and with a rich ecosystem. Just the ticket!

And I wouldn't even say that people went for it because it was "hot new" back in the day. People went for it because it solved their problems. Being in fashion was never it's strong point, Rails and Node/Express did far better with that.

> In other words, Django used to be picked because it was the hot new thing

I picked up Django in February 2006, in fact the (very cool) boss I had back then picked it up for me and my other programmer colleague, I think it was version 0.96 (or maybe 0.92 ?, not sure). Anyway, we didn't pick Django because it was "new and cool", my boss had a business to run (which folded two years later for unrelated reasons), but instead because Django seemed like a pretty good candidate back then at doing a decent job. Which it did, admirably well, I think ours might have been one of the first lead-management systems built on top of Django's admin interface (lots of monkey-patching involved, which is still one of my "guilty" soft-spots as a programmer 10 years later).

Anyway, web programming back then was, how to put it, in a very interesting place. In Python's case we had Zope/Plone, which had sort of its separate ecosystem doing weird (but sometimes very interesting things) like an object-oriented database (hello, ZODB!) with a very interesing routing mechanism on top of it, Quixote (https://wiki.python.org/moin/Quixote) and mod_python (on top of which I built my first personal Python web-project). PHP was the hot thing, even though not the newest thing, Java's web offering consisted in Struts and some other thing which had a related name for which you needed to be an "Java architect" in order to put 2 forms and 3 templates together, Rails was just about to be launched, ASP was a joke (at least according to my other programmer colleague, who was also teaching ASP at University) and I won't comment on Perl, of which I know not too many things (and which seemed pretty cool, I have to admit).

Considering all this of course that Django (and Rails) was a huge breath of fresh air. People nowadays take things like JS web frameworks for granted, but until not too long ago the web was a very different place (which sometimes I really miss).

Well, that's basically it. It certainly isn't cutting edge, nor anything close to it. It's stable and boring. Some people like that, believe it or not.

And there's still a lot of stuff - even new projects - written in Java and on the JVM.

Sometimes maturity trumps fads, in other words boring > hot.

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

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.

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

Ansible problem is 100s of libs that are python2 only. Sysadmins never got python3...

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

No, that's 1.11 (a LTS release)

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.

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?

As someone who picked Django over Rails ~10 years ago and has used it for everything since then-- I wouldn't bother.

Django and Rails, like Python and Ruby, look more and more similar as time goes on. Not because they are becoming more similar, but because the web ecosystem around them has become a lot more diverse. If you want a break from Rails, learn Phoenix! Or Node, I guess.

Furthermore, with the advent of fat front-ends, the utility of both of these frameworks has gone down in absolute terms. When they first came out, front-end features like form generation and HTML templating were really important, but now they're arguably better to avoid. (That's why channels are so important to the future of Django.)

That said, I still like Django a lot and use it all the time. I don't want to discourage you from learning it. But I wouldn't do it because you're trying to make a leap from Rails.

What a refreshingly honest answer...thank you. It's not often you see that sort of candor.

I was personally a Rails guy, then switched to learning Django, but had the experience you note...both frameworks solved many problems which aren't as relevant in this age of SPAs. I suppose if you really liked Django's ORM it might be worth it, but doubt there's a huge amount of value to be gained. YMMV.

In the age of SPAs, I have actually found Django with DRF to be incredibly invaluable. The efficiency of just having to specify a few models and then getting a full REST API for them with minimal effort is tremendous.

I suppose if the framework, community and ecosystem are on par with each other, then the deciding factor would be the language.

Exactly. I've chosen Django because of Python.

>front-end features like form generation and HTML templating were really important, but now they're arguably better to avoid.

Why is that?

It's the DRY principle. If you have a single-page app, the frontend needs to know how to render everything (using JS), so rendering on your backend as well is, at best, duplicated work. There may also be complications at the boundary of those regimes, like how your frontend initializes on top of server-rendered HTML.

At most 5% of apps should be a SPA. Seems rash to pick your only web framework on 5% of apps.

Not OP but I feel like it's because JavaScript has evolved enough that some of the niceties they offered before doesn't make sense. I like using Ember.js and doing client-side validations is pretty darn easy without complicated JS. Additionally, having inherited a legacy Rails project that uses `remote: true` in it's forms, it is causing more of a headache to fix these legacy issues.

Validating data should always be done on the server. You should never, ever, trust the client.

That's not to say you can't do (or shouldn't do) form rendering, processing, error/success handling, etc. on the client-side, but the server should always have the last word on the validity of what you send.

The typical recommendation to getting started with Django, is to go through the tutorial included in the documentation [0]. This is the path I took several years ago, it'll get you up and running in no time.

I found Two Scoops of Django[0] to be a great resource if you want to follow the best practices for a Django app. The authors are also very active in the community.

[0] https://docs.djangoproject.com/en/1.10/intro/tutorial01/

[1] https://www.twoscoopspress.com/products/two-scoops-of-django...

Seconded on both points - found the Django docs themselves to be AMAZINGLY helpful (to the point where I feel spoiled) when learning. Found another toy project or two online to learn and play with, then read through Two Scoops to really cement the ideas more and get some ideas on best practices AND went back to it a few times during development for reference.

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/

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/

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/

My 2 cents is that if you have a lot of Rails knowledge it's probably not worth changing.

However, Django has a much better security track record, and Python is used in a lot of other fields so learning the language has broader benefits. For these reasons I absolutely recommend Django to newbies over Rails.

If you plan to use Django as an API server, you might be interested in Lightweight Django (http://shop.oreilly.com/product/0636920032502.do), which shows you how to design and build an API server using Django, Django Rest Framework (another great Django related project) and Backbone on the front-end.

2010 called, it wants its tech stack back ;)

Half-implemented, broken and cool is more fun than solid and battle-tested, and that's perfectly fine so long as you don't get yourself fired over a bad choice - have a great time. Honestly, I used to be more novelty-driven, too. But battle-tested and boring has its place.

Now get off my lawn.

Sorry, the off-lawn module depends on left-pad. :(

Admittedly but Backbone is _still_ a good intro to Front-end frameworks because it has a steep learning curve upfront instead of, say, angular that seems easy enough to pick up until you try to tackle non trivial applications.

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.

No any reason. RoR is great. But as a personal experience, most of my pals who came from the academic area ( Python in scientific programming is beautiful...), we felt more familiar with Django because, you see, it's more straight to use Python in producing dashboards or other Web based app. But I've personally found that the main thing is to generate backend data (Json, http request...) with Django/RoR and build the fronted with Js.

If you want to use in an effective manner your Python skills acquired in scientific programming to build web apps,...I would recommend Django.

The online documentation will serve you well. I recently had to learn django for my new job and I must say that I enjoyed every bit of the learning process.

Because it will be easy to learn coming from a Rails background (or so I have heard). In terms of features I think they are pretty equal.

My suggestion: don't bother. The "less magic" things comes because of Python's explicitness (not because of Django at all).

Well, there was actually a concerted effort to remove magic (back in pre 1.0, in a branch aptly called "magic-removal".) The problem was that convention-over-configuration was tripping a lot of new people. It was actually the reason I decided to go with Django over Rails.

That said, I feel like nowadays Rails and Django are more or less equally capable, so choosing one over the other might be a matter of language and ecosystem preference over anything else.

on top of django tutorials, I found this tech blog to be excellent source of HOW-TOs

http://www.marinamele.com/django

There is no point unless you are going to using a lot of Python's scientific computing apparatus, or you want the ability to rewrite "hot" code in Cython for better performance. If you are primarily focused on social-esque or CRUD-heavy apps there isn't really an upside vs Rails.

What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend, I'd rethink your architecture before you consider switching languages.

> What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend,

I have worked on a lot of projects that involve science related stuff and Django.

Directly in the web app backend was relevant mostly for GIS apps that could take large raster data, process it based on the user's wishes, apply the right projections, apply a colormap and return an image to be shown on a map. Python has great tools for that sort of thing and it doesn't have to take much longer than rendering a HTML template does.

Other than that, the CPU intensive science-related stuff usually ran in background tasks, with Celery or otherwise. But those would still need access to the database, so why not use the same Django models for the web backend and the background tasks.

I find that once Django is part of your Python code it tends to find its way to all parts of it, through the ORM, settings files, handy admin interfaces, management commands as scripts, and so on.

Of course anything long running is going to be run as a service via something like Celery. That being said, there are actually a lot of things you can do with SciPy for which the turnaround time isn't sufficient to justify dispatching multiple messages.

Come one, even scientific work will require a front end at some point. Not everything will be CPU intensive. And even if it is it may need some user interaction to get the task started - even if it is just uploading data to be processed offline.

But you don't need the scientific code inside your Django app—it should live in a separate process. What I'm saying is there is no need to have the scientific code directly inside the Django app.

There are plenty of web based scientific apps. Genome browsers for example. Why would you have those in a separate process, when its essentially a crud app?

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

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.

[1]: https://docs.djangoproject.com/en/1.9/internals/release-proc...

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.

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

It was withdrawn from the 1.10 release about 3 months ago, I think:

https://groups.google.com/forum/#!msg/django-developers/QRd4...

Also see:

https://groups.google.com/forum/#!topic/django-developers/24...

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.

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.

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!

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.

1.4 to 1.5 is the really painful upgrade. The rest are much less so. Especially after 1.6.

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.

For others:

https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdo...

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.

if you can screw your old migrations it's not a big deal.

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.

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.

You get similar issues with libraries that you use for flask or pyramid too though, if you don't upgrade it for 4 years.

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.

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.

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

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.

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

How did I miss that? Thanks so much!

* django-medusa https://github.com/mtigas/django-medusa

* django-bakery https://github.com/datadesk/django-bakery

* django-freeze https://github.com/fabiocaccamo/django-freeze

* django-staticgen https://github.com/mishbahr/django-staticgen

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?

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

> 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/

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

Yeah dependencies are always going to be an issue unfortunately. Django can make as many recommendations as it likes, but you're still at the mercy of all other dependencies.

Moving from 1.9 to 1.10 is different than moving from LTS to LTS. The hope is that 3rd party packages will be testing against LTS releases at the minimum, which should allow you to make the jump after packages have time to update themselves.

> Moving from 1.9 to 1.10 is different than moving from LTS to LTS. The hope is that 3rd party packages will be testing against LTS releases at the minimum, which should allow you to make the jump after packages have time to update themselves.

This is true. Good point.

TL;DR: always update Django to the latest version you can, if your app is a little bit bigger, jump from one LTS to another may take some time.

LTS is great, if there is some reason that you cannot upgrade when new release comes. But if you use any plugins, just update to the latest version your all plugins support. Some plugins like (or even need) to use internal Django API's and if your app becomes pretty big, you may be tempted to use those internals in some places as well, which makes upgrades more painful due to internal API changes.

Speaking from personal experience of upgrading pretty big and rather legacy app from Django 1.4 to 1.8. Took more than a week.

1.10.

Always start new projects with the latest version. You don't want to be stuck on really old versions when you eventually upgrade.

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.

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.

The upgrade to 1.8 should not be difficult. It all depends how you are setup now. I write django fulltime. Ping me if you need help. :)

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

Reply on news.ycombinator.com