周六的时候麒麟子说4.x还在开发中
那么问题来了 cocos3.x会不会和2.x或者cocos3d一样后面无了？（毕竟也没少干这种事）
现在我们的项目还是2.x 引擎层面的bug基本是靠我们自己解决。
还有4.x和3.x的跨度是否会和2.x一样改动那么大 对于旧项目升级有啥需求么？
我说的是 新功能会统一放入 Cocos Creator 4.x。
目前 90% 的资源依然是在 Cocos Creator 3.8.x 上面。
关于这个问题，我只想说：
任何软件，都是不停向前迭代的。就像这个世界的转动，不会因为某一个人的怀念旧情而停下。
1赞
麒麟子大佬就是it界的诗人
1赞
大佬~
4.x版本加一个接口吧
释放 bundle 的时候，除了资源，把这个bundle 下的 js文件也一起释放
为啥不是放3.9呢
另外，在3.8稳定并取得 50% 以上的全版本使用占比之前，感觉最好还是别盲目推出不兼容的新版本
我想说的是 unity2018到现在基础的c# 代码控制api那些兼容非常好 甚至能一件升级。对于开发者来说 我们更期望的是一个稳定的版本 。用户不care 到底是creator做的还是2dx。
用户关心的是游戏效果，体验。
我希望cocos后面的功能新增能非入侵的形式新增功能。
一个维护十年 二十年以上的产品 不可能引擎发一次版本重构一次
2赞
3.8lts后续版本的应该能，但是4.x这种大版本的更新肯定会有一些破坏兼容性的改动，还有你确定unity 2018后的版本能一键升级2018年unity还是5.x哦
2.x和3.x都是两个产品了 2.x现在完全被放弃了 等4出来3也好不到哪去
从我的经验来说运行起来问题不大
4.x 的native最好只把最底层代码交给opengl， 比如将buffer 给opengl ， buffer在js层算好ouput， 不要再做任何处理， 这様使用者在代码维护上才有优势， 不然一段代码在web调试时好好的， 一到native发现不行， 还要改c++代码， 这不纯增加开发者工作量麻。
我认为可以有破坏性改动非常重要，这是引擎能丢掉包袱持续前进的保证，毕竟随着时间的推移，当初的设计很可能会过时。
只要不是在新版本中某些特性直接被移除了（2.x -> 3.x 就很多这种情况发生），那么大部分兼容问题都能通过开发自动迁移工具来解决。
只是有时候 “避免破坏性变动” 成了人们懒惰，不愿意前进的借口。
即使是最要求稳定、向后兼容的编程语言，也有像 Rust 的这种 “ stability without stagnation” 的 Edition 机制，至少在原则上是允许做出破坏性变更的设计的，而不是像某些语言一样声称永远向后兼容，然后糟糕的设计甩也甩不掉。
6赞
当初你退出文坛，我是极力反对的
6赞
支持破坏性改动，
舍不得肉套不着狼啊
这样啊 就算是4出来了 那么前半年的时间里 你不要碰它就是了 看着就行了 过了那个劲再用保证你心情能好很多
我举个例子cocos3.x 的刚开始的版本 spine的核批功能都没了。我说的破坏性的功能是指类似的（可能大家对破坏性这个理解不一样） 。3.x甚至js直接砍掉了 强迫开发者用ts。
如果3.x中我们需要的功能还不如2.x ，我们没有理由去升级啊。4.x也是同理。
我举个例子 值得我们去升级的理由例如
dots 它能带来更棒的性能 以及更好的控制。
4.x 准确地说，还处于规划阶段，大家不必在意，专心研究 3.8.x 就行。
3.8.x 作为 LTS 版本，会长期更新，解决大家关注的易用性、性能、稳定等问题。
2.x 与 3.x 之间，由于引入了 3D 管线，所以在引擎接口上改动确实很大，导致了极难兼容。
4.x 和 3.x 本质上属于同一体系，引擎接口上不会大动，因此不会出现 2.x 与 3.x 之间这样的鸿沟。
并且，目前在 4.x 的规划中，我没有看到有脚本机制和引擎接口层的改动，大放放心。
麒麟子大佬，为什么是4.x，而不是3.9、3.10或者3.11呢？
如果出了3.9， 请问 3.8.x 这个 LTS 的意义何在？到时候你会更纠结。
大家对版本号好像有什么执念…不就个数字吗 重点不是看更新了什么吗
嗯嗯，重点看功能更新，稳定性，易用性，稳定性。