Firstly, consider that commercial software vendors do not typically issue personal apologies to users when they push out upgrades due to finding a regression. If you apologize for making a bug, you've gone beyond the industry norm.
A software team shares the responsibility for all changes. Or if they don't they should. There should be a peer review process for every commit, and tests to catch regressions.
The regression you caused slipped in because:
If you are working some feature X, and some feature Y breaks without being detected, it's not entirely your fault. It's partly because the behavior of Y is not covered by a regression test suite.
(In addition to reverting your commit, you should add a test case somewhere which reliably passes when your bad commit is absent and reliably fails when it is present.)
Of course, you're responsible for tracing all the ways which your change can affect existing logic, but the less detailed is your regression suite, the more time-consuming is that tracing process, and the more likely you are to miss something in spite of a good effort.
Also, it may be outright impossible to avoid breaking some behavior that is neither documented nor covered by a test. Why? Because a behavior that is not documented or test simply does not exist as far as you're concerned.
Some other developer knows about the behavior, and then several months or years down the line remembers it and tries it. Then you get blamed: hey you broke this Y thing with your X change back in 2014! Except Y thing is only documentedin that developer's head, and not covered by a test.
Never accept responsibility for "breaking" something that was never documented or covered by a test but expected by someone to work. Call the situation out.
Sometimes the downstream users rely on undocumented, untested behaviors. Things can break that way; you ship a new version and the users complain that something that used to work doesn't work. Still, do accept some personal responsibility for something like that. It's nobody's fault. Every complex system ends up with behaviors that are not documented. Only very technical users (engineers) understand the implications of discovering some "feature" and relying on it without checking that it's actually a feature. Ordinary users assume everything that seems to work is a feature. If you break something like that, the blame is distributed: the users should have known not to rely on something undocumented; your software, overall, could have been better in validating against unexpected input combinations, and checking internal contracts, so that there are fewer such undocumented behaviors (ideally none); or else, your team, including QA people, could have been better at identifying such undocumented behaviors, and communicating them to documentation people so they could warn the users.
