The scope of Lotus is huge and ambitious. We’re working only on volunteering time of all the great people around the framework.
What we achieved until now is remarkable, but to complete what’s in our roadmap in a decent time span, we need to narrow the scope of our effort.
We’re trying to open as much as possible the creation process of Lotus, involve new people to contribute to features. This is all great and inclusive, but it requires more effort from us and more time to get straight to the goal.
Me and @trung_le discussed to cut in the near future the Ruby VMs that we support. To maintain different Ruby versions with different implementations and features is becoming more and more unsustainable for us.
Sadly, Ruby is what MRI is. Other implementations will eventually follow. The problems are about the time that those maintainers will take to port MRI features into their alternative distributions.
It’s really far from me to criticize those teams. I can totally relate with them on how OSS is hard.
However, we just can’t wait for uncertain timelines.
With the release of MRI 2.2.0, they shipped a really important feature that solves a lot of problems for us: collectable symbols. Until that release, we didn’t had the chance of symbolize untrusted inputs. The risk was to expose applications to DoS attacks. So we had to put in place security mechanisms and at the same time offer convenient ways to access input via “indifferent access”.
To avoid symbols has a big perf impact for Lotus::Controller and Lotus::Validations. We aim for fast and secure applications, and now we can have both those qualities in Lotus if we support Ruby 2.2+.
Our proposal is to only support MRI 2.2+ and JRuby 9000. Those two VMs offer compatibility with Ruby 2.2 features.
We want to wait another month for JRuby to get out with a stable release and wait for MRI 2.2 wider adoption. Then we want to release a minor version of all the gems to mark the line with the past.
We’d love to hear your opinions.