4 ms·
The 1.8/1.9 switch was problematic and can be seen in parallel with the python 2.7/3.x switch. Rails 2/Rails 3 was a similar big jump that reengineered the whol
by Argorak 13y ago
The 1.8/1.9 switch was problematic and can be seen in parallel with the python 2.7/3.x switch. Rails 2/Rails 3 was a similar big jump that reengineered the whole framework. Rails 4 was a much tamer release in that regard.
But one has to realize that 1.8 was the series of Ruby that was started _before_ Ruby even got popular (I started Ruby using 1.6, which was even more problematic). So being aggressive in breaking stuff with the next iteration (basically, to do it proper, with more manpower and data to work on) also opened up a lot - for example, Ruby 1.9 to 2.0 is a much simpler switch and I have many clients running 2.0 now and testing on 2.1.
The fear I always have with python 2.7 is the distant future. It just irritates me to have a huge migration in front of me. The Rubyist in me wants to keep up with the current state of things.
- cookiecaper 13y ago1.8/1.9 and 2.x/3.x were handled very differently by the respective communities. That's evident even from the version numbers.
- halostatue 13y agoThat's because until well into the development of Ruby 1.9, Ruby was still using the odd (dev)/even (release) approach. 1.9 introduced things that were different, and it wasn't stable enough for production use until 1.9.2, at which point work on 2.0 started.