Thanks for the solution.
Thanks for the solution.
I've been using this framework for 4.5 years and it's a never ending battle and again although I was out of line, I know moving to a different framework is absolutely the right decision for a public-facing website. Even with my new technique for resolving ajaxified URLs for Google, there is probably just going to be far too much noise (dom elements) to signal (actual content) for an ExtJS site to benefit, so I'll focus on the way bigger picture of public-facing ajaxified URL's not relying on ExtJS.
Anyway, do note however that at the following URL I have removed the line items regarding the tooltips bug in 4.2.0
We have not been able to upgrade since 4.1.2, almost a year ago due to show-stopper bugs. These weren't one-off type of issues but fundamental. We're now waiting until 4.2.2 to see if we've hit the Sencha no-bugs sweet spot. In Sencha's latest bugs in 4.2.1 I asked for a potential fix and was told how much it would cost us.
I think there is some problem in Sencha's software release process. Sencha can quickly idenfy a bug, quickly fix a hug, but they keep their users waiting a few months for a new release for the bug fixes. What's worse is new bugs are likely introduced in the new release.
There's nothing wrong for software to have bugs. I think Sencha needs to accelerate their release cycles.
I agree. This is really the problem.
The goal of point releases should be to get to a version that is stable. As such, the point releases should be frequent and official so the larger community will be willing to use the release.
4.2 introduced lots of new bugs, many that completely broke code working in 4.1. 4.2.1 fixed some bugs and introduced more. This is divergence not convergence.
The worst part is that for any bugs introduced in 4.2.1, the public will have to wait until 4.3 for fixes that come along with whatever new complications the major changes in 4.3 introduce.
I really hope Sencha reconsiders their policy of only releasing the first point-release to the public and keeping subsequent ones commercial-only. I even have a commercial license but the practice of withholding patches to new bugs and then just leaving them to fester in public even when fixes are released privately has terrible effects on the ecosystem and drives me crazy when I'm trying to help non-commercial-license holders. This strategy has created a minefield where every public release has a tradeoff of fixes vs new issues.
There has to be better ways to differentiate the commercial offering that doesn't involve leaving many people, and pretty much all the beginners, to deal with known+fixed bugs.
What I'd love to see is commercial licensors getting direct access to a library of hotfixes (overrides organized by bug #) while the public gets _every_ point release when it's ready.
Chief Architect @ Jarv.us Innovations
Co-captain @ Code for Philly
Jarvus builds and optimizes top-quality Sencha Touch and ExtJS apps for open-source projects and clients of all sizes.
Don't waste time with bugs that have already been found and fixed by the community, compile our tried and tested hotfixes packages into all your projects: https://github.com/JarvusInnovations/sencha-hotfixes
Maybe they are too busy with their conference, and they don't have a chance to take care of the bugs now.
+1 for the suggestion about a repository of official hot fixes.
I've been using / following Ext-JS since the early 2.x days. One of the biggest things I miss about the way Ext-JS LLC operated versus how Sencha operates today is the willingness of devs to post specific bug fixes in the forums. I'm not saying those handling the support forums aren't doing a good job - I've seen many very professional interactions that have helped out a great deal. However, it cannot be denied that something has changed. It used to be that you could post a suspected bug in the forums and then get an override from Jack or Brian or some other core dev in a matter of hours. Now, we usually just get a message indicating it's fixed in the next release. I'm not sure if this is a step to indemnify against overrides that cause problems, if it's to encourage support subscriptions, just a result of Ext-JS going corporate, or something else.
This is why I think official overrides for support subscribers is a really great idea - it lets us effectively build our own release that is *just* bug fixes without interfering too much with the Ext release cycle. Community supplied overrides for bug fixes are great, but they can only take us so far - having official ones really makes sense.