Ext JS 4.0.2 RC released

Ext JS 4.0.2 RC released

Today we're seeding a release candidate for Ext JS 4.0.2 to all Ext JS developers. Usually we don't go through a beta/RC phase for patch releases but in this case we wanted to give an earlier build to gather feedback as early as possible.

* The gray theme makes its return
* The docs have seen many improvements, and the guides have been structured to be more comprehensible for new Ext JS 4 developers
* Lots of performance improvements to grids and layouts, informed by your test cases and feedback on the forums (more details on exactly what changed will come with the full release)
* Over 200 enhancements, bug fixes and performance improvements since 4.0.1

While this build contains significantly improved performance and stability, it hasn't completed all stages of our internal QA process and there are a few known issues, notably:

* Disabled tabs have visual defects on IE6
* Button group headers are not correctly aligned (all browsers)
* Form field anchoring is not perfect in all examples in IE6

We are working on closing out these remaining issues at the moment and expect to have a finalized build available shortly.

We will create formal release notes once this release is final, but for everyone who wants a preview of what we've changed here's an export from the bug tracker since 4.0.1. Once we're done with 4.0.2 we'll organize these by component:

Thanks, there have been a lot of optimizations to layouts, which were often called so many times that things looked right but took a long time getting there. We've got a couple of those left to iron out before 4.0.2 final (like the one you mention), which is exactly why we're sharing this one ahead of release

We certainly aren't done yet with this release and have plenty of feedback to act on regarding new features, tweaks to APIs and bugs in our functionality. That said, we try to release builds as often as possible to deliver high priority updates to our community as quickly as we can, rather than holding them back so that we can keep adding fixes.

Hopefully this approach is valuable to everyone developing with our SDKs and pitched at about the right balance of fix count vs time between builds. I'm interested in feedback if we can do this better though.