4 ms·

I read that I'm not sure what the point is?

stefantalpalaru 12y ago
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.
- jgroszko 12y ago
  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...
  - stefantalpalaru 12y ago
    That is broken by design.
    - jsmeaton 12y ago
      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.
- lazerscience 12y ago
  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.
  - stefantalpalaru 12y ago
    > 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. I tried and it was a complete waste of my time: https://code.djangoproject.com/ticket/18494 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?

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.

jgroszko 12y ago
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...
- stefantalpalaru 12y ago
  That is broken by design.
  - jsmeaton 12y ago
    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.
lazerscience 12y ago
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.
- stefantalpalaru 12y ago
  > 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. I tried and it was a complete waste of my time: https://code.djangoproject.com/ticket/18494 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?