> They break backwards compatibility

For the most part, they think they things through a lot and most importantly they document breaking changes. Their approach is an absolute dream compared to, say, updating xcode/iOS apps. It's a total shit show at Apple.

Ha, if you think that updating iOS apps is bad, try updating all your node modules to the latest version without anything breaking.

It's like Russian Roulette with your code. Maybe something will break, maybe you'll get off easy!

This is why continuous integration is good. If the latest version of a dependency breaks something, you'll know sooner rather than later.

Whilst your menacing tone is not really in tune with HN's guidelines (and you'd be wise to edit it and soften it up I think), I think this is an important point to discuss. I don't have many Django projects, but even I have experienced weird, sometimes intermittent API breakages on minor version bumps that I've had to spend hours debugging, only to find that Django upstream changed the way some function behaved.

I think the project is venerable and I have respect for it in general. It's one of the most accessible major open-source projects for newcomers; like I said, I'm not a heavy user and I've already submitted a couple of patches and had them merged. But issues like this one are worth pointing out.

Is there a deficiency in the test suite? Is the open and accepting nature of the community that I just praised the cause of this issue, because it leads to a bias against thorough vetting? I really don't know enough about the project to know, but it'd be nice if they figured it out.

In my experience, many reasonably large projects suffer the same issue. The "deficiency" is always in the test suite, but that's because a particular code pattern or property wasn't envisioned and isn't properly tested. The test suite is limited by the patterns of the developers, and if you do something that's technically possible but outside of what they are thinking, they could make seemingly innocuous changes that break your code. If you start from the docs every time, following the recommendations, Django is pretty good.

I manage a modest project and there are plenty of issues with corner cases that I knew were possible but never could reproduce. As people stumble upon them and report issues I can update the test suite to avoid stepping on the landmine again, but that doesn't change the fact that we've barely scratched the surface.

I usually work lower down the stack, and, frankly, that level of code quality would not be acceptable. (But what you describe matches my experince writing application level code)

Here is a strawman low level test: Randomly generate a sequence of nonsensical (but legal) API calls by randomly generating some data layout, then feed it into a state machine of legal API calls (eg. CRUD), and check the return values. Once that runs for 10 minutes without crashing, extend the test to be multithreaded and run with 1000 thread for a few hours. Dial back the runtime to 60 seconds, and stick it in the regression suite.

As long as there is a well defined API, this finds most bugs (and I also write targeted tests to exercise tricky / error prone paths).

Any thoughts on why it is so much harder to implement reliable high level frameworks? Is it dynamically typed languages / lack of encapsulation, or something more fundamental?

You are finding crash bugs with your test. Most Django regressions are logic bugs. Like some library overwrote a method and that method got a new param in Django, breaking the library. Good libraries with good tox suites catch this. Not all libraries are good.

The example you gave (wrong number of parameters in an override) would be caught by any sane statically typed language. (Though if you are distributing updates to .so's you need to explicitly check for ABI compatibility)

I had to search for Tox. It seems like analogous tools would be nice for statically typed "systems" languages too, though there is less need for them there (more bugs are caught at build time, instead of after deploy).

Debian sort of does the same thing when it builds packages, but only checks compatibility with current versions of dependencies. It would be nice if they also checked / tracked compatibility breakage (the "not all libraries are good" observation is language independent, and a "n days since we broke users of this library" label would be great).

I put all sorts of asserts in the state machine logic (this is the 'check the return values' part). When sufficiently clever, such checks can confirm a surprising range of high and low level behavior.

I don't have any projects using Django but they have an LTS model - surely you don't need to update to avoid being vulnerable? Just security patches?

For three years, if you release your project the day the LTS comes out.

How long do you expect?

Java 7 had less than four years of support.

Ubuntu Desktop LTS was three years, and starting with 12.04 it increased to five years.

That's a language runtime and an operation system known for their stability, forming the bottom of very wide and deep ecosystems.

Show me a web framework with a 3 year LTS, and I'm overjoyed.

Symfony has 3 year LTS plus a year security support after. http://symfony.com/doc/current/contributing/community/releas...

Well the new model will have a new LTS every 2 years, with guaranteed compatibility as long as you didn't have any deprecation warnings. So you get 2 years to fix warnings, then a guaranteed working new version. I find it hard to believe anybody is doing anything better in this space.

If you start your project on the day a LTS comes out, you'll theoretically be compatible with the _next_ LTS, 2 years later, so in some ways it's up to 5 years until you need to change your code.

Django releases tend to add useful features/optimizations, and have very light upgrade effort. Most devs will WANT to upgrade to the latest stable.