11–20 of 76 posts
Regression testing. It'd be a nice regression test to have: - Rails pegged at a particular version number and test the runtimes. - Ruby runtime pegged at a particular version and test Rails versions
As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.
As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.
As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.
This seems like a pretty minimal set of changes to get a 19 year old piece of software running.
As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.
At that time odd release numbers where development versions, until this policy changed a bit later and 1.9 became an actual "GA" release.
The 1.8 -> 1.9 is really Ruby's "Python 3" moment, as it similarly improved String encoding handling, but the breakages were much more limited and it also came with pretty significant performance improvements, so the community didn't split like Python 2 and Python 3.
If you follow Ruby's development, or watch Matz talks, you see that avoiding a Python like split is really his number 1 concern.
As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.
The painful one is 1.8–>1.9, because that's where Ruby's string grew encoding awareness.
Going from 2.7->3.0 was not nearly as painful (mostly dealing with warnings and some code being removed from the standard library as gems that people can use if they want).
I still maintain code that is nominally 1.8 compatible and it works just fine on 3.2 (I haven't yet tested on 3.3).
What is surprising about this exercise is how little code needed to be changed on code designed for Ruby 1.8 to allow it to run on Ruby 3.3. The author doesn't say how long they spent on this, but it looks like 3–4 hours for a fairly complex piece of infrastructure code.
How much effort would be required to run Django 1.0 on Python 3.12? At least this much, I’m sure. I suspect more, but I don't know the 2->3 differences well enough to be able to estimate that.
As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.
If the author reads this, I think you shouldn't bind space to the side menu, I (hope) many people know you can scroll with space.