lts发版频率下降的同时，lts的支持时间也需要相应的扩展一些，不然没有意义。
嗯，嗯，嗯（必须三个字）
版本快速迭代有利于产品的快速发展，发版速度变慢，新功能上的就慢了
看了下大家的建议，大多数是从运维去考虑的，认为追不上新版本，可是为什么要追新版本呢？
如果是因为产品生命周期到了，那跟发版速度没啥关系了，你期望的是增加产品生命周期
如果是想用新功能，那应该期望版本快速迭代啊
2 年一个 LTS，仔细打磨更好。
支持以年月份命名，一目了然
优质的产品 都会不断的迭代更新
箱子把我带来了，期望我能把它带走
修复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影响生产使用或者需要频繁去升级，可能会增加很多时间和人力成本去维护，反而会影响大家对数据库的原则