lts发版频率下降的同时，lts的支持时间也需要相应的扩展一些，不然没有意义。
嗯，嗯，嗯（必须三个字）
版本快速迭代有利于产品的快速发展，发版速度变慢，新功能上的就慢了
看了下大家的建议，大多数是从运维去考虑的，认为追不上新版本，可是为什么要追新版本呢？
如果是因为产品生命周期到了，那跟发版速度没啥关系了，你期望的是增加产品生命周期
如果是想用新功能，那应该期望版本快速迭代啊
2 年一个 LTS，仔细打磨更好。
支持以年月份命名，一目了然
优质的产品 都会不断的迭代更新
箱子把我带来了，期望我能把它带走
1 个赞
修复BUG，以及性能优化很重要。
小步快跑在前期功能不齐全的时候可以快速提升产品可用性。
现在 tidb 基本上能满足日常使用了，可以压缩一下, 稳一稳。比如说如果以前 10个新特性组成一个大版本，现在压缩一下，改成20个。
如果短时间没那么多新功能做，就做bugfix，把现有的版本修复的稳定一些。至于 DMR，内部看看就行吧，没多大必要放出来，谁会去用呢？
我靠。刚码字好几百，怎么突然不见了。再精简说一下吧。这个之前给过建议。
1.从6.5开始，性能和功能已经满足绝大多数使用场景。
2.过多版本对于厂商产品管理和用户选择都有痛点；
3.注重可靠性和稳定性，打造lts经典版本。比如2大开源数据库pg和mysql。pg12,mysql-5.7即使官方宣布EOL了，照样有很多用户在使用。
码字不易，箱子有木有？ 
可以参考下node.js呢
确实过于快了
稳定性可靠性高于一切
功能追平阶段可可以一年一个lts ，后期可以2年甚至更长一个大版本。
其他时间可以做好补丁，插件周边的开发。
太快了我升还是不升呢？
其实相比于版本更新速度，大家更在乎稳定性和低bug率，因为一旦安装完成后，如果因为bug影响生产使用或者需要频繁去升级，可能会增加很多时间和人力成本去维护，反而会影响大家对数据库的原则
数据库产品不比应用类产品，确实更加在意稳定性，长时间打磨会更好一些。
稳定性比较重要，一般六月份，能更好的测试和打磨产品，不用着急版本出的过于频繁
更新太快一些第三方调度工具支持会比较麻烦，升级的话存在很多风险，对TIdb升级会有很多顾虑。建议一年一个长期维护的版本，最多两个。
从产品管理角度来看，也要控制的。版本太多，会增加管理负担。另外可能开发会考虑需求，发版时间。重点就考虑功能实现，可靠和稳定就考虑的少一些。数据库不是普通产品，不适合快速迭代的模式，bug多，一直不较少。尽管功能，性能很强大，也没人敢用。老司机更关注可靠性、稳定性。
选我选我选我
+1， 现在 TiDB 的基本功能都已经比较完善了，感觉可以放缓新特性的 GA 速度，一个大的新特性肯定是需要长时间的打磨才能把各种问题都发现到，一旦新特性打上了 GA 标签，研发对它的关注度就会降低，团队主要精力可能就放到另外一个新的特性的开发/测试上了，这样就变成实际的用户来承担发现 BUG 的功能，这个时候即便能修复，就跟上面很多人提到的，又要频繁升级 TiDB 集群版本了，体验真的不好。。。
现在我感受比较深的是，TIDB 新特性的 GA 不代表真正生产可用， 有时候等上一年真的用起来还是很多小问题。6.1 的Placement Rule in SQL， 7.1 的资源管控，7.5 的TiFlash 存算分离，这三个新特性都是 GA 后等了一段时间才在生产上用的，但都或多或少遇到了问题。
1 个赞