5 ms·
The goal here is to slim down Rails as much as possible. A slim Rails means fewer moving parts, and an end product that's easier to comprehend. "Batteries inclu
by jherdman 17y ago
The goal here is to slim down Rails as much as possible. A slim Rails means fewer moving parts, and an end product that's easier to comprehend. "Batteries included" sort of features are candidates for extraction.
- minalecs 17y agowhile i do agree with the thoughts leaner, smaller, modular is better.. one of my main issues with rails has always been upgrading from releases have always been a painful thing to do. It was much worse pre rails ~2 , but in general as a lean start up.. its just such a pain point, that I do wish for more stability, and better planning of deprecation of features.
- dhh 17y agoIf we need what we were going to do before we did it. We'll, we'd just do it then and there. Ruby code is simple enough that the process from good idea to implementation is small. That makes road maps meaningless because you can only map what you know. And if what you know can be turned into code instantly, why not do the code directly instead of writing down that you're going to do the code in the future? We do deprecate everything gracefully, though, and there'll always be a good alternative to go to. For error_messages_for, all you need to do is add 1 line to your Gemfile and you're all good. Not exactly shattering. If you find other, specific places where backwards compatibility is broken without proper deprecation or with a suitable plugin to carry you over, please report. We consider that a bug.