Approximately hundreds of small bug fixes, across much of Rails. The fixes include some important ones for database types, time comparisons, thread issues, record reloading, etc.
IMHO these fixes address dozens of bugs that could cause major puzzlement for a typical Rails developer.
Thanks to all the contributors for excellent work on this release.
That has been the reason I always avoid huge frameworks like RoR.
If I was to hit a bug like this, I wouldn't know where to start debugging. How do people deal with obscure bugs in the framework with something like RoR?
Then you share the test case in a bug report, and collaborate to fix it. Fixing it usually involves a source code dive.
With Rails's reasonably well documented and reasonably well written codebase it's usually possible to grok the source and dependencies even coming to it cold. With the possible exception of arel.
Ruby's dirty tricks department (monkey-patching third-party objects) and duck typing together are a real boon to debugging.
> That has been the reason I always avoid
> huge frameworks like RoR.
Even if you don't upgrade, this is something you should backport using a monkeypatch.
> Restore aborted transaction state when disable_referential_integrity fails due to missing permissions.
Bugs from 5.0.0 or from 4.whatever? If it's the latter then bug fixes should be going there, not in a new major release.
(there is a separate branch for 4.x.y releases, but that's only security patches nowadays)
There are plenty of stable companies out there running Rails apps and I'd venture a guess that a lot of start-ups probably still use it as it's great for small teams and rapid-prototyping.
On a side note, we also have hired devs who don't have Ruby experience but who are generally smart, experienced people, who know more than one programming language and are willing to learn whatever stack they need to for getting the job done.
Are there other gems and resources available for accelerating the migration from 4 to 5? Been thinking about doing it for a project for a little while.
We contacted the Rails team early on about this issue and worked closely with them to have this issue solved. Now that 5.0.1 is released we are at liberty to disclose details about this security issue.
I've written a blog post[2] on the problem, using OS X network shaping tools and a simple app to demonstrate it. Rails apps running on Passenger were never affected as Passenger implements response buffering for regular requests as well as websockets connections. Note that even popular reverse proxies like Nginx don't perform response buffering for websockets as far as I know, so this is something to be aware of if you're running on other frameworks than Rails as well.
[0] GH merge of patch: https://github.com/rails/rails/pull/26646
[1] GH related issue: https://github.com/rails/rails/issues/26409
[2] Blog post: https://blog.phusion.nl/2016/12/21/actioncable-under-stress-...
Thanks!
Thanks!