The main problem I see is that you are releasing each 6 months, which is too rare. There's a reason why Scrum says a maximum of 4 weeks per Sprint. Because at the end of the 4 weeks, the increment needs to be potentially releasable. You don't have to do it, but it has to be in this state.
So, because the releasing cycle is too long, your customers raise their issues as bugs, which you are forced to fix before the new release. You can't convince them to wait for the release because it takes 6 months, which is clearly too long.
What you should do, as a company?
You should choose a Sprint length that your customers will accept to have the bugs fixed. Obviously there will be some critical bugs which need to be solved ASAP. Allocate to those 10% of the Sprint. Keep in mind, it's a team metric.
The rest of the bugs go in the Product Backlog and get prioritized along with the features you are developing.
Let's assume you do this and you start a new Sprint with some features and bugs in it.
Now you have three types of bugs:
- The bugs you've selected in the Sprint Backlog. Just fix them.
- The bugs that appear during QA of the features you have selected in the Sprint Backlog. You need to fix them in the same Sprint to deliver your feature.
- Critical bugs not in your Sprint Backlog. Use the 10% allocated time to fix these when they appear (eg. production bugs).
At the end of the Sprint you deliver a new version which has:
- Some bugs fixed.
- Some features developed (and the bugs found during QA already fixed)
- Critical bugs fixed with priority. (10% of your time).
The customer can accept this because it's reasonable to wait 2-4 weeks for some minor bugs, while the critical bugs get fixed ASAP.
Now, if 10% of the Sprint length is not enough, then you have Technical Debt. You may increase to 15% or maximum 20%.
You need to anticipate these bugs. You need to refactor or redo some of your code if you know it has critical bugs that your customer will discover. Create some items in the Product Backlog to anticipate these bugs and talk your Product Owner into giving them high priority. Anticipate your customers' bugs and you'll have a better Sprint Planning and time management.
Lastly, you may have a customer which claims every bug is critical. When you receive it, have a look at it. If it's not critical (eg. some button in the UI which never worked), ask the Product Owner to discuss with the customer or do it yourself if you can deliver the message.
When assessing priority/criticity put yourself in the customer's shoes. It may be a small technical bug, but if the customer is losing money on it, then it has high priority. How high? Ask the Product Owner.
If you allocate 10% of your time to fix critical bugs and actually use more of it, your Product Owner should decide which of the Sprint Backlog items should not be delivered. It's simple: you put something in, take something out.