[jrochkind1]

Rails _needs_ to produce security-patch-only patch releases.

This won't be foolproof; there is no such thing as foolproof in software development. There can still be unintentional regressions in security-patch-only releases (and even new security vulnerabilities), as well as new security vulnerabilities in other releases.

Yes, nothing is foolproof. But you can work at improving your quality. Yes, there are other things Rails could do to improve quality, including trying to actually do some variation of semver.

But the most obvious thing with the highest benefit/cost that Rails team could do is always release security patches in security patch only releases, so developers can apply security patch only releases and minimize their exposure to new regressions when doing so. Git should not make this hard to do, just cherry pick the security-patch commits into a branch created off the last release, and release it as a patch release seperately from any other changes.

Am I missing something?

[jeremymcanally]

Well, the release policy published by the Rails team states releases like this are supposed to only have security patches, but for some reason it wasn't followed here. I'm not sure why other than the frantic "zomg there's a security hole must fix it!" fray that may have clouded their judgement.