这一个版本2.12.3做了挺久的。虽然涉及到的issue只有9个，但是其中有些issue涉及到了LF的核心数据结构的变动。为了能让LF的源码设计更加优秀，是做了大量的优化的。
如果你在使用2.12.X系列的版本，可以无缝升级。如果是以下版本，请看官网的升级指南。
在之前版本中，这一直是循环体系中不太完美的地方，开发者只能取到当前层的循环下标/迭代对象。而无法取到上层的值。之前版本没提供也是因为涉及到了底层的对象结构的变更，没有很好的思路去入手。
在这个版本中，我们终于提供了这一个特性。不仅能取到上一层的循环下标/迭代对象，还能取到前N层的。
关于这个特性的详细使用方法请参照【常规组件->次数循环组件】以及【常规组件->迭代循环组件】。
其实这个问题和循环嵌套获取N层下标的问题类似，都是属于底层对象结构的不完善导致的。我们这个版本花了很长时间去思考了这个问题，并从底层去解决了本质问题。
Solon是一个优秀的纯血国产应用开发框架，LF一直对Solon有支持，但是在之前的版本中，在solon中开发声明式的组件一直存在问题。后来得益于solon作者的帮助，这个问题才得以解决。
现在你可以在solon体系中更好的使用LiteFlow了。
测试用例数我认为直接反映了一个开源项目的可靠性和稳定性。所以我们在对待测试用例这件事上是有和对待核心代码同样的极致追求。
每一个issue，每一个特性，每一个bug，每一个增强，我们都有相应的测试用例来佐证，并且所有的PR提交都会要求通过所有的测试用例才能合入。
我们一直积极在回答社区里的各种问题。随着社群人数不断激增，问题也在不断变多。
我们在回答的同时也发现了很多现象，我总结了下主要有以下几类：
1.LF概念性的问题
2.开发中碰到使用LF常见的问题，反复被提问
3.文档有明确的显示提及，但在社区内还是被反复提问
4.某一个功能特性使用有问题
5.同自己公司业务结合设计方面的问题
6.提出建议性LF需要改进的点，新增的特性
7.报LF使用过程中已经明确的Bug
目前LF一共有15个群，每天都会有非常多的社区问题，我们做不到细致的回答每一个人的问题，而这种模式也并非健康长久的模式。所以我也在思索如何去优化社区答疑这个体验。
对于问题类型一，LF官网可能会在之后增加一栏去专门解释概念，用在哪里，如何选型方面的一些文章。目前的确这方面的解释在官网上有缺失。
对于问题类型二，反复被提问这是我的问题，而非开发者的问题。常见的问题虽然在LF官网有专门栏目，但是没有及时更新和增加，在之后，我会去花时间建立一个比较全面的常见问题知识库供大家查阅。
对于问题类型三，这个只能希望使用者多去看文档，在社区群里也只会给一个指引，而不会过多的去解释。
对于问题类型四，我们建立庞大数量的测试用例一方面是为了保障项目稳定，另一方面也希望使用者在碰到问题时能去源码查询下对应的测试用例，但我遗憾的发现，只有很少的开发者会去查看测试用例，估计能查看源码的人更少了。但是我之后还是会引导社区里的同学去查看对应的测试用例。
对于问题类型五，这个我真没办法回答，尤其是XXX业务可不可以用，要如何设计这类问题，因为我并不精通使用者公司的业务，拿LF如何设计业务这种问题和业务紧密绑定，需要对业务要有很深的理解才可以。
对于问题六，七，其实这两类问题，是对LF本身有很大推动作用的。目前我们都会根据问题去建立相应的issue，并且推动迭代和修复。
特性 #I9T6PB 嵌套循环获得任意外层的下标或者对象 https://gitee.com/dromara/liteFlow/issues/I9T6PB 增强 #IAH00W 增加在LiteflowResponse中超时节点的Id获取方式 https://gitee.com/dromara/liteFlow/issues/IAH00W 增强 #IAMBU8 ELBus 增加普通节点构建方法 https://gitee.com/dromara/liteFlow/issues/IAMBU8 增强 #IAOW43 在solon体系中支持声明式的组件 https://gitee.com/dromara/liteFlow/issues/IAOW43 增强 #IAGJ2F 在使用最新版决策路由功能时发现SPI加载有报错问题 https://gitee.com/dromara/liteFlow/issues/IAGJ2F 修复 #IAERN6 隐式子流程嵌套报错 https://gitee.com/dromara/liteFlow/issues/IAERN6 修复 #IAIH89 在SQL插件多个数据源都能检测执行通过的情况下，有可能会出现连接泄露 https://gitee.com/dromara/liteFlow/issues/IAIH89 修复 #IAJR32 修复在ParallelStrategyExecutor可能出现的NPE问题 https://gitee.com/dromara/liteFlow/issues/IAJR32 修复 #IAOICK GraalJavaScriptExecutor 这个类的compile()方法中新开的context没有关闭，可能有隐患 https://gitee.com/dromara/liteFlow/issues/IAOICK
评论删除后，数据将无法恢复
LiteFlow v2.12.3 正式版本发布，国内好用优秀的规则引擎框架
前言
这一个版本2.12.3做了挺久的。虽然涉及到的issue只有9个，但是其中有些issue涉及到了LF的核心数据结构的变动。为了能让LF的源码设计更加优秀，是做了大量的优化的。
如果你在使用2.12.X系列的版本，可以无缝升级。如果是以下版本，请看官网的升级指南。
嵌套循环获取N层下标/迭代对象
在之前版本中，这一直是循环体系中不太完美的地方，开发者只能取到当前层的循环下标/迭代对象。而无法取到上层的值。之前版本没提供也是因为涉及到了底层的对象结构的变更，没有很好的思路去入手。
在这个版本中，我们终于提供了这一个特性。不仅能取到上一层的循环下标/迭代对象，还能取到前N层的。
关于这个特性的详细使用方法请参照【常规组件->次数循环组件】以及【常规组件->迭代循环组件】。
隐式子流程嵌套的问题
其实这个问题和循环嵌套获取N层下标的问题类似，都是属于底层对象结构的不完善导致的。我们这个版本花了很长时间去思考了这个问题，并从底层去解决了本质问题。
在Solon体系中支持声明式的组件
Solon是一个优秀的纯血国产应用开发框架，LF一直对Solon有支持，但是在之前的版本中，在solon中开发声明式的组件一直存在问题。后来得益于solon作者的帮助，这个问题才得以解决。
现在你可以在solon体系中更好的使用LiteFlow了。
测试用例数提升到2056个
测试用例数我认为直接反映了一个开源项目的可靠性和稳定性。所以我们在对待测试用例这件事上是有和对待核心代码同样的极致追求。
每一个issue，每一个特性，每一个bug，每一个增强，我们都有相应的测试用例来佐证，并且所有的PR提交都会要求通过所有的测试用例才能合入。
其他要说的
我们一直积极在回答社区里的各种问题。随着社群人数不断激增，问题也在不断变多。
我们在回答的同时也发现了很多现象，我总结了下主要有以下几类：
1.LF概念性的问题
2.开发中碰到使用LF常见的问题，反复被提问
3.文档有明确的显示提及，但在社区内还是被反复提问
4.某一个功能特性使用有问题
5.同自己公司业务结合设计方面的问题
6.提出建议性LF需要改进的点，新增的特性
7.报LF使用过程中已经明确的Bug
目前LF一共有15个群，每天都会有非常多的社区问题，我们做不到细致的回答每一个人的问题，而这种模式也并非健康长久的模式。所以我也在思索如何去优化社区答疑这个体验。
对于问题类型一，LF官网可能会在之后增加一栏去专门解释概念，用在哪里，如何选型方面的一些文章。目前的确这方面的解释在官网上有缺失。
对于问题类型二，反复被提问这是我的问题，而非开发者的问题。常见的问题虽然在LF官网有专门栏目，但是没有及时更新和增加，在之后，我会去花时间建立一个比较全面的常见问题知识库供大家查阅。
对于问题类型三，这个只能希望使用者多去看文档，在社区群里也只会给一个指引，而不会过多的去解释。
对于问题类型四，我们建立庞大数量的测试用例一方面是为了保障项目稳定，另一方面也希望使用者在碰到问题时能去源码查询下对应的测试用例，但我遗憾的发现，只有很少的开发者会去查看测试用例，估计能查看源码的人更少了。但是我之后还是会引导社区里的同学去查看对应的测试用例。
对于问题类型五，这个我真没办法回答，尤其是XXX业务可不可以用，要如何设计这类问题，因为我并不精通使用者公司的业务，拿LF如何设计业务这种问题和业务紧密绑定，需要对业务要有很深的理解才可以。
对于问题六，七，其实这两类问题，是对LF本身有很大推动作用的。目前我们都会根据问题去建立相应的issue，并且推动迭代和修复。
2.12.3完整更新列表