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