I hear that every time I make a release for the project I am working on. My answer is always the same. You are working with humans, humans make mistakes. I made mistakes, my project leader made, even the customer made mistakes. There was a visual bug on the start page 7 people tested and nobody noticed, because it wasn't something they expected to change.
This happened once. As long as it doesn't frequently happen it's fine. They dealt with it immediately. Exactly how it should be.
Just so you know for that to discover what need to happen:
- This part of the content needs to be tested. However, why? There was no changed reported.
- There needs to be time to test this.
- The tester needs to know how it was before the patch. What if he or she is new?
- The tester needs to actually care. He or she might just look for game breaking bugs.
And after all that the patch might still go live, because it isn't serve enough. However such thing really should be noted in the patch notes.
The problem here is you are expecting the same quality something from a between two and four week release cycle as a half a year one. While this is understandable, reality has shown us it's simply not possible. In this short time span you have an error rate of 35%. The only real thing that works for this is completely change the way releases are made.
I am getting off topic... It's not my intention to just "lecture" you, but you really set yourself up for disappointment. Software development just doesn't work that way, unless you speaking of some really big project with a lot of manpower. Like the big open source frameworks and programs.
Long story short. Ninja patches will happen in the future. Most of them unintended. Some purposely not mentioned. The best thing to do would assemble some voluntary testers. Who better to ask if sometime went wrong, then the people playing the game frequently? We could at least reduce the surprises that way.