5 ms·

> its healthy consideration for backwards compatibility Is this a joke? They break backwards compatibility with every minor version, wasting tens of thousands

> its healthy consideration for backwards compatibility Is this a joke? They break backwards compatibility with every minor version, wasting tens of thousands of man-hours all over the world - time that, if we're honest, is not exactly billable. Most people don't upgrade because of this and keep on using vulnerable versions. It's good that they are trying to kill the project. It saves newbies from stepping into the tar pit.

mcintyre1994 10y ago
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?
- Joeboy 10y ago
  For three years, if you release your project the day the LTS comes out.
  - paulddraper 10y ago
    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.
    - desas 10y ago
      Symfony has 3 year LTS plus a year security support after. http://symfony.com/doc/current/contributing/community/releases.html#long-term-support-versions http://symfony.com/doc/current/contributing/community/releas...
  - mcintyre1994 10y ago
    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.
  - hobarrera 10y ago
    Django releases tend to add useful features/optimizations, and have very light upgrade effort. Most devs will WANT to upgrade to the latest stable.
  - collinmanderson 10y ago
    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.
cookiecaper 10y ago
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.
- TAForObvReasons 10y ago
  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.
  - hedora 10y ago
    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?
dplgk 10y ago
> 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.
- strange_quark 10y ago
  Ha, if you think that updating iOS apps is bad, try updating all your node modules to the latest version without anything breaking.
  - astrodust 10y ago
    It's like Russian Roulette with your code. Maybe something will break, maybe you'll get off easy!
  - andrewfong 10y ago
    This is why continuous integration is good. If the latest version of a dependency breaks something, you'll know sooner rather than later.

mcintyre1994 10y ago

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?

Joeboy 10y ago
For three years, if you release your project the day the LTS comes out.
- paulddraper 10y ago
  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.
  - desas 10y ago
    Symfony has 3 year LTS plus a year security support after. http://symfony.com/doc/current/contributing/community/releases.html#long-term-support-versions http://symfony.com/doc/current/contributing/community/releas...
- mcintyre1994 10y ago
  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.
- hobarrera 10y ago
  Django releases tend to add useful features/optimizations, and have very light upgrade effort. Most devs will WANT to upgrade to the latest stable.
- collinmanderson 10y ago
  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.

cookiecaper 10y ago

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.

TAForObvReasons 10y ago
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.
- hedora 10y ago
  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?

dplgk 10y ago

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

strange_quark 10y ago
Ha, if you think that updating iOS apps is bad, try updating all your node modules to the latest version without anything breaking.
- astrodust 10y ago
  It's like Russian Roulette with your code. Maybe something will break, maybe you'll get off easy!
- andrewfong 10y ago
  This is why continuous integration is good. If the latest version of a dependency breaks something, you'll know sooner rather than later.