LiteFlow v2123 正式版本发布国内好用优秀的规则引擎框架 - OSCHINA
应用介绍
这一个版本2.12.3做了挺久的。虽然涉及到的issue只有9个，但是其中有些issue涉及到了LF的核心数据结构的变动。为了能让LF的源码设计更加优秀，是做了大量的优化的。
在之前版本中，这一直是循环体系中不太完美的地方，开发者只能取到当前层的循环下标/迭代对象。而无法取到上层的值。之前版本没提供也是因为涉及到了底层的对象结构的变更，没有很好的思路去入手。
在这个版本中，我们终于提供了这一个特性。不仅能取到上一层的循环下标/迭代对象，还能取到前N层的。
关于这个特性的详细使用方法请参照【常规组件-次数循环组件】以及【常规组件-迭代循环组件】。
其实这个问题和循环嵌套获取N层下标的问题类似，都是属于底层对象结构的不完善导致的。我们这个版本花了很长时间去思考了这个问题，并从底层去解决了本质问题。
Solon是一个优秀的纯血国产应用开发框架，LF一直对Solon有支持，但是在之前的版本中，在solon中开发声明式的组件一直存在问题。后来得益于solon作者的帮助，这个问题才得以解决。
测试用例数我认为直接反映了一个开源项目的可靠性和稳定性。所以我们在对待测试用例这件事上是有和对待核心代码同样的极致追求。
每一个issue，每一个特性，每一个bug，每一个增强，我们都有相应的测试用例来佐证，并且所有的PR提交都会要求通过所有的测试用例才能合入。
目前LF一共有15个群，每天都会有非常多的社区问题，我们做不到细致的回答每一个人的问题，而这种模式也并非健康长久的模式。所以我也在思索如何去优化社区答疑这个体验。
对于问题类型一，LF官网可能会在之后增加一栏去专门解释概念，用在哪里，如何选型方面的一些文章。目前的确这方面的解释在官网上有缺失。
对于问题类型二，反复被提问这是我的问题，而非开发者的问题。常见的问题虽然在LF官网有专门栏目，但是没有及时更新和增加，在之后，我会去花时间建立一个比较全面的常见问题知识库供大家查阅。
对于问题类型三，这个只能希望使用者多去看文档，在社区群里也只会给一个指引，而不会过多的去解释。
对于问题类型四，我们建立庞大数量的测试用例一方面是为了保障项目稳定，另一方面也希望使用者在碰到问题时能去源码查询下对应的测试用例，但我遗憾的发现，只有很少的开发者会去查看测试用例，估计能查看源码的人更少了。但是我之后还是会引导社区里的同学去查看对应的测试用例。
对于问题类型五，这个我真没办法回答，尤其是XXX业务可不可以用，要如何设计这类问题，因为我并不精通使用者公司的业务，拿LF如何设计业务这种问题和业务紧密绑定，需要对业务要有很深的理解才可以。
对于问题六，七，其实这两类问题，是对LF本身有很大推动作用的。目前我们都会根据问题去建立相应的issue，并且推动迭代和修复。
