AFAICT Rails does point releases by just taking whatever's at head on the 3.x master branch, building a release candidate there, and iterating until nobody is reporting bugs.
This isn't a security patch - a stable branch with deliberately cherrypicked fixes - it's just a plain old "point release." And as is to be expected with Rails at this point, point releases break apps.
It's not particularly common in my experience. For example I upgraded several apps to 3.2.13 this week after tests, and haven't seen any breaking changes, and most of those apps have come up from 2.x without unexpected bugs (though I think I did have to make changes for 3.0 before going into production). YMMV, and I might have missed a subtle bug caused by this change but have checked since the github post and can't find any issues.
This bug looks like it was caused by the interaction of Github's scoping with a small change to Rails to attempt to unify the query building a little and fix a potential security issue. Where queries are merged where they apply to the same column, but (probably unintentionally) they were not merged when one was a string and one a key, which happened in some circumstances with scopes. Would love to see a slightly clearer explanation of this bug - the article doesn't provide one.
They could (and usually do) isolate the security patches in a separate release with just minimal changes - at least that would make the process more manageable, but unfortunately in this case I don't think that would have helped, as the change was directly related to a change for security and just had unintended consequences.
In fact I think from their blogpost github merged the CVE patches separately after testing rather than using the update, so having a separate security release wouldn't have helped them either, it's just an unfortunate confluence of circumstances for them due to a gap in testing (perhaps on both the Rails side and the Github side). See
The only lesson I draw from it is that perhaps Rails could slow down their release cycle a little, issue more RC builds, and encourage large users like github to try them out extensively in development environments (hard to persuade people to do this on small point releases though). Up to now they've done a pretty good job IMHO and I've not seen many issues crop up, particularly with security releases, which are usually straightforward.
Comments
AFAICT Rails does point releases by just taking whatever's at head on the 3.x master branch, building a release candidate there, and iterating until nobody is reporting bugs.
This isn't a security patch - a stable branch with deliberately cherrypicked fixes - it's just a plain old "point release." And as is to be expected with Rails at this point, point releases break apps.
And as is to be expected with Rails at this point, point releases break apps.
As a primarily Django guy with an interest in Rails... is this hyperbole/overstatement or is this a common perception?
It's not particularly common in my experience. For example I upgraded several apps to 3.2.13 this week after tests, and haven't seen any breaking changes, and most of those apps have come up from 2.x without unexpected bugs (though I think I did have to make changes for 3.0 before going into production). YMMV, and I might have missed a subtle bug caused by this change but have checked since the github post and can't find any issues.
This bug looks like it was caused by the interaction of Github's scoping with a small change to Rails to attempt to unify the query building a little and fix a potential security issue. Where queries are merged where they apply to the same column, but (probably unintentionally) they were not merged when one was a string and one a key, which happened in some circumstances with scopes. Would love to see a slightly clearer explanation of this bug - the article doesn't provide one.
They could (and usually do) isolate the security patches in a separate release with just minimal changes - at least that would make the process more manageable, but unfortunately in this case I don't think that would have helped, as the change was directly related to a change for security and just had unintended consequences.
In fact I think from their blogpost github merged the CVE patches separately after testing rather than using the update, so having a separate security release wouldn't have helped them either, it's just an unfortunate confluence of circumstances for them due to a gap in testing (perhaps on both the Rails side and the Github side). See
https://github.com/blog/1440-today-s-email-incident
The only lesson I draw from it is that perhaps Rails could slow down their release cycle a little, issue more RC builds, and encourage large users like github to try them out extensively in development environments (hard to persuade people to do this on small point releases though). Up to now they've done a pretty good job IMHO and I've not seen many issues crop up, particularly with security releases, which are usually straightforward.
It was certainly the case on the 2.3 "stable" branch two or three years ago: http://david.rothlis.net/rails/experience_report/#stable_bra...
From my own anecdotal experience it is true. The ruby gem responsible for most point release breakages affecting me is probably activerecord.
I'm also a Python dev, and my observation from several threads here (and elsewhere) is that the perception is quite common.
IANARailsDev, obviously.