3 ms·
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
by 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 agoThat is broken by design.
- jsmeaton 12y agoBroken 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.