I see the docs have been updated to point to 4.2.2, so hopefully it's officially released?
Should be in the support portal very soon.
Update: The new releases are now available in the support portal.
Last edited by Gary Schlosberg; 1 Oct 2013 at 9:01 AM. Reason: update
Lifecycle management for your web apps
Got it. Unfortunately stable 4.2.2 appears to be from a nighly near September 18, given the minor version number. I guess that's why I was seeing reference to 4.2.3 already, because the nighlies for 4.2.2 have really been for 4.2.3 for weeks.
Code:Build date: 2013-09-18 17:18:59 var version = '126.96.36.1994'
Yes, it looks like 188.8.131.524 was the latest build pinned by QA. I'm told that because of this the release is rarely the very latest nightly. Apologies for any confusion.
Lifecycle management for your web apps
To make it clear: 4.2.2 release will be available only to Sencha Support subscribers or to public? Thanks.
184.108.40.2064 is not sufficient so don't bother with that one.
TBH i don't think they are ready to release just jet. IMHO 4.2.2 will never be released as GPL but that's just speculation ofc. 4.2.3 is on it's way tough, might be able to snatch that one as a GPL release maybe this month, who knows.
I don't feel comfortable with Sencha any longer, no milestones to pin on, it's all too quiet
For those interested: no change in nightlies since September 24th
Personally, I'm a little frustrated with the Sencha release cycle. I've started treating the stable releases as beta. I've tried to keep up with latest versions because it becomes a pain to upgrade it later, and even minor updates to the releases break down the application. So, I'm constantly in a debugging mode, and waiting for the bugs to be fixed before tooling any major features. To confuse it further, the bug fixes are only available to the support subscribers and everyone else is left hanging till the next public release, which in turn breaks down some other functionality, and the cycle starts all over again.
I know that this topic has been discussed several times, but I just wish it was simpler to manage it and upgrade it in my application.
The company I work at we are currently replacing our Ext JS 3.4 architecture to 4.x. But I had something working since 4.0.2 and when I upgraded each time the library updated I had little issues that only took me a day or 2 to fix it. And just to let users know our software isn't a small one.
We currently have close to 1,000 screens in Ext JS 3.4 with grids that get into millions of rows for a single grid.
It's your choice to buck the system provided or go with the flow they are providing.
I've been using Ext JS since 2.0 I'm used to having to rewrite everything to work with the library.
Of course this is just my opinion you can take it however you want to take it, it is not any disrespect to anyone. Just what I've noticed reading forum posts.
Glad to hear someone that is happy with the way it is going on. I'm also from the 2.x branch. To be honest you make it sound like you take out of the box examples and work on them. Or maybe you need to clarify the 'flow' you are talking about.
In my experience it's those corner cases that just don't work. 1 deviation from the example or 1 extra mixin and 1 nesting too many and stuff is broken. They are fixing it yes but with every build it seems another one pops up, that's what irritates people. And yes fixing it yourself might be a solution. I've fixed some very complicated stuff in the 4.2.2 branch from which i know for certain that not anybody could fix.
We all send bug reports in but never hear anything about it for a pretty long time. Something is missing here that Sencha needs to hear pretty bad but they won't listen. Most parts of the forum are totally ignored.
1) Bug report - tracking system (screw licensing this just needs to be there)
2) Milestones milestones milestones
3) Fixes to bugs number 1 priority
Currently i still have 30 overrides standing that with every nightly build are still needed even when the release notes say they fixed it,... that's just annoying.