How expensive are your bugs for your customers? That is, do they badly need them fixed ASAP, or would rather prefer stability in a status quo?
How expensive is a mistake in your product? That is, is shipping a bug a nuisance or is fatal?
For a product with expensive bugs (e.g. accounting software or aircraft control systems), you'd have long release cycles, rare cumulative releases, and a large share of time spent on creative manual testing.
Since your users live on the bleeding edge currently, the above must not be your area.
For a product with inexpensive bugs, you'd have very fast release cycles, mostly automated testing, and potentially multiple releases a day.
The smaller a release is, the less creative testing it needs, because a change is small and its impact anywhere else in the system is usually zero. The smaller is the set of changes, the smaller is the chance of their unanticipated interplay.
Also, the smaller is the change in the new release, the easier it is to roll back to the previous known good release. (Being able to do so in a matter of minutes is always useful.)
So, "release early, release often".
Get a role of a release engineer; usually people take shifts doing releases. The (today's) release engineer determines when to cut the release, that is, what changes are included in it, makes sure the build of the release branch is made and tested automatically, then does a few manual tests of the changes that don't have automated tests (e.g. subtleties of UI interaction).
If a release passes the tests, the release is promoted to the "blue" ("beta", "canary") state; a bit of production load is diverted to it, or it's made available for download by customers that signed up to beta releases.
If a release fails a test, the release is postponed, and the problem is communicated to whoever is responsible. If a fix is trivial, it can be backported to the release branch, and the process repeats. If the fix is large / takes long, the release can be canceled, or an earlier state of the master branch can be cut as the release branch.
To my mind, with a setup like this, a release should not be a big deal, something requiring a lot of intellectual effort. It will take time to handle all this, though. Allocate this time; measure the time actually spent, and adjust. The payout is fewer bugs shipped (as opposed to bleeding edge), and faster bug fixes (as opposed to releasing once a year). Usually it's worth it.