http://zengrong.net/post/2188.htm 由Quick转向原生lua
Z大都放弃quick-x 怎么办！！
我早就说了，quick-x 被收进cocos2d-x 后迟早要挂的 ，cocos2d-x 摆明就是对quick-x 不重视，甚至怕 quick-x 多人用
cocos-js 效率有quick-x 高？ js有lua快？
quick-x 团队还不如像以前单干，放开手脚。。。
被收进cocos-x 后 感觉被各种忽视，各种不兼容和bug 都随着 （ 为了配合cocos2d-x） 而来
说实话， 3.3真心不好用， 我还是觉得3.2的比较好！！！
quick-x 3.2 时还是保持在2.X那种便捷
3.3融入cocos-x 后肯定会有不少问题的
我更新quick是止步于3.2了，3.3之后架构改的太大，没法跟了……
淡淡的忧伤…
强烈推荐使用2.25plus 3.x都是坑
暂时还在用2.2.5plus。 2x的方式确实是最好的，安装也方便。现在3.x每次安装都要叫IT输管理员密码。
明年2月份必须上64位，2.x版本支持64位还是有点悬吧，迟早要更新到3.x版本的
到底cocos2d-x团队怎么回事，不太了解呀。在此坐听各位大侠解说
http://quick.cocos.org/show/quick-2014-autumn/assets/player/KeynoteDHTMLPlayer.html#0 这个 对于quick是进步 还是倒退 新手不敢妄下结论 还请给位大神 给个说法
首先要谢谢楼主对quick的支持，因为只有关心才会有担心，这是对我们quick团队的激励；当然，也同样是鞭策。
有一些问题，需要作一些说明，以免引起大家不必要的担心。
cocos2d-x在脚本的方向确实是更偏重js和html5，lua团队在资源的支持上相比是要少很多。不过，比起之前只有廖大一个人做quick，也不能说支持比以前差了。同时也不存在打压quick的问题，公司一直是希望quick向前发展的。当然，要求quick更好的与cocos2dx兼容，更多的支持其他cocos相关工具如ide和ccs等，这些是有的，可能这就是让大家觉得quick被收购后受到“束缚”的原因；不过，话说回来，这其实也是很大一部分开发者的需求；所以quick并不只是在公司的要求下做这些工作，同时也是在开发者的需求下来做的。
quick的3.2版本，是在cocos2dx 3.x版本基础上发布的第一个版本。这一版本其实是沿袭了之前quick版本的做法，对cocos底层引擎进行了修改以适应quick的框架。因此，对于用过quick 2.x版本的开发者来说，是很容易上手的。然而，对于许多刚开始使用quick的开发者来说，与cocos底层的不一致还是给他们带来了很多困惑；特别是在ide和ccs的使用上，有很大的差异；这其实是很不利的。
底层修改后，另一个问题是，当cocos引擎升级之后，quick要随之升级将变得困难。特别是在cocos的C++部分变动很大的情况下，更新底层引擎和保持顶层api不变有可能会出现两难的选择。而对于在quick中添加了自己的C++模块的开发者来说，升级后底层引擎的变化更是会造成非常大的麻烦。实际上，Jacky，也就是Z大，在楼主引用的他的文章里提到的“quick2.2.3到2.2.5的不兼容”，正是因为升级底层引擎引起的，Jacky的项目中加入了很多自己使用的C++模块，在底层有大的变化的情况下，确实是非常难以进行调整和升级的。
因为上述的原因，从3.3开始，quick开始尝试对cocos作更好的兼容。团队的工作成果也是非常好的，quick的框架与cocos底层作了很好的分离，对底层代码几乎没有修改，因此升级只需要作简单的代码更新即可。
然而，3.3rc0版本现在看来步子又迈得过大了一些。由于完全对cocos底层没有修改，所以rc0直接将quick变成了“插件式”的安装，即需要开发者先装好cocos2d-x 3.3，然后再安装quick需要的其他文件。这样，quick的安装包可以很小，方便开发者下载。但从3.3rc0实际使用的结果来看，这样做的体验其实非常的不好，由于开发者还要安装和配置cocos2dx，反而多出了不少的工作，也产生了更多的一些问题。
因此，后续的版本，quick将重新把cocos底层重新集成进来，但仍然基本上不修改cocos底层的代码，同时保持了quick在框架上的扩展。这样的版本，在使用上和以前的quick版本类似，同时又能够兼容cocos，也能够非常好的支持ide等cocos工具。目前的版本已经有一些开发者进行了试用，得到的反映还是很好的。
前两天也刚好和Jacky在QQ上有过交流。其实，如果仔细看楼主引用的文章，可以发现，Jacky之所以在3.x上暂时不考虑使用quick，恰好是因为quick 3.2仍然与cocos有差别，他不希望在未来遇到类似从2.2.3升级到2.2.5的困难。quick 3.3其实是没有问题的，因为在底层上quick 3.3就是cocos2dx 3.3，用quick 3.3其实就是用cocos-lua，只是在上层框架有扩展而已，把扩展的部分直接去掉就是完全的cocos-lua了。当然，由于3.3rc0还不成熟，所以Jacky最后提了一句等待新版本发布----我想，这也代表着大家对quick的期待吧，同时也让我们quick团队的每个人都感到了一份沉甸甸的责任。
廖大已经对quick做了新的规划。在未来，会有“包管理器”等新特性加入，模块管理会更方便。cocos很可能完全变成一个quick的模块。用户可以自己选择对应的模块版本。各模块的升级不会影响到主模块和其他模块，“不兼容”的问题，将会成为历史。
最后，还是再感谢大家的支持。希望对我们quick团队多提意见，让quick发展得更好。
2x不支持ios 64位吗？ 那样的话确实很悲剧
这个还没试过，不清楚，坐等大大们确认
这是用KeyNote做的？感觉动画效果很赞啊
七月，快确认一下： quick-x 2x版本不支持ios 64位吗？
2.x现在用的是32位的库，特别是luajit是没有64位的库的，所以必须进行修改
感谢 阳光七月 讲诉了这么多 quick-x 的发展历程。
我只是希望 这个很好的框架 能变得更好，跟多人用，所以未免有些担心。
但现在从你的quick-x的规划看来。。。
只能说，廖大还是深谋远虑，quick-x会变得更好的
我正在尝试直接从quick3.3开始使用, 目前版本是3.3rc0. quick 3.2找不到合适的开发软件已经退不回去了.
我分别尝试了
adt-bundle-windows-x86_64-20130717
adt-bundle-windows-x86_64-20140321
adt-bundle-windows-x86_64-20140702
android-ndk-r9b
android-ndk-r9d
android-ndk-r10c
cocos2d-x-3.3rc0
quick-3.2rc1
quick-3.3rc0
python2.7.3
python2.7.8
目前能够成功编译quick3.3rc0的开发环境是
adt-bundle-windows-x86_64-20140702
android-ndk-r9d
cocos2d-x-3.3rc0
python2.7.8
jdk1.8.0
apache-ant-1.9.4
尝试了小2周, 期间尝试了各种组合, 查询了网上不下50个各种开发配置的帖子
还因为官方文档上说明各个库都需要使用最新, 还回退了ndk版本(从最新的r10c退到r9d, r10c编译不通过, 貌似不支持android-20)
目前没有任何方案能够解决语法提示的问题, 一直在等quick3.3rc1的发布
同时希望官方文档在开发环境配置上可以写的更严谨一些. 毕竟项目的开发环境配置不只是包括开发调试, 还有后续打包等很多工作.
quick现在的版本控制欠缺严谨和解决方案的一致性, 用来做工程的时候, 非常担心后继版本的向前兼容能力.
还有建议加入版本 history, 官网上现在只针对最新版本做说明, 想选择旧版本完全找不到说明文字.
ps: 不知道我这半个月的环境配置是不是属于无用功了
我使用quick是非常早的，2.3 之前的版本都开始使用的。也经历了2.3，升级到 2.4、2.5、3.0、3.2、3.3. 可以学到很多东西哦。 继续支持quick。