The ruby community has a pretty extreme forward-looking stance. Generally, the ruby development community (on ruby itself as well as open source ruby code) seems to prioritize innovation and improvement over backwards compatibility and maintenance of old code. It would be nice to think you can do both, but it’s unrealistic, development resources and ingenuity is limited, you have to dial one side back to dial the other side up — the ruby community tends to move the dial relatively far to the ‘innovation over maintenance’ end.
This has plusses and minuses.
On the positive side, we get to keep moving forward with better API’s and better code — in the stdlib, in our open source dependencies. The fact that pretty much everyone made the somewhat difficult jump from ruby 1.8.7 to 1.9.3 within just a couple years is pretty amazing. Compare to Python 2->3. (A separate post could be written about what led to ruby’s 1.8->1.9 success; it’s not only a matter of will). At this point, while there are still people with legacy 1.8.7 apps for various reasons — one of the reasons is hardly ever that an open source dependency they have won’t work on any later rubies. That’s pretty amazing.
The negative, of course, is that sometimes it seems like I spend way too much time running on a treadmill just keeping my existing code current, as new versions of ruby or dependencies are released that are (in large or small) not entirely backwards compatible. It feels like just yesterday that I updated all my apps from ruby 1.8.7 to 1.9.3 (a challenging and ‘expensive’ process), and now 1.9.3’s got a year of life left. And some people who can’t afford that time are still stuck on old codebases which are no longer compatible with current stdlib or open source releases, and don’t receive upstream security patches anymore. (This can especially be an issue with large ‘enterprise’ infrastucture. For instance, Twitter still runs at least some ruby 1.8.7-based code.)
Fortunately, at least, I think lots of people did take some lessons from how time-consuming and painful the ruby 1.8.7->1.9 migration was (and the similarly timed Rails2->3 migration), and are trying to make future migrations less painful.
I think it likely that the migration from 1.9.3 to 2.0 or 2.1 (I’ll prob skip all the way to 2.1 why not) will be relatively painless. In fact, my biggest concerns areabout the task of smoothly managing the transition of installed/used ruby on my deployment and staging machines, rather than in the application software itself. I guess I’ll probably go to Rails4 at the same time. (I can’t figure out when Rails 3.x will stop receiving even security patches, maybe when Rails5 comes out? Not sure when that is either. But it worries me.)
https://www.ruby-lang.org/en/news/2014/01/10/ruby-1-9-3-will-end-on-2015/
Support for Ruby version 1.9.3 will end on February 23, 2015.
Today we are announcing our plans for the future of Ruby version 1.9.3.Currently this branch is in maintenance mode, and will remain so until February 23, 2014.
After February 23 2014, we will only provide security fixes for 1.9.3 until February 23 2015, after which all support will end for 1.9.3.
We highly recommend you upgrade to Ruby 2.1 or 2.0.0 as soon as possible.
Bibliographic Wilderness 