Quick answer: Rank by impact, weigh it against effort, draw a clear cut line for the update, and ship, deferring the rest without guilt. Deciding what goes in an update is about drawing a defensible line, not fixing everything, the bugs above the line ship, the ones below wait for the next one.
Every update is a container with limited space, and you have more bugs than fit. The decision of which to fix before shipping forces a cut line: some bugs make this update, others wait for the next. Made well, this is a quick, defensible call based on impact and effort. Made poorly, it is endless agonizing that delays the update while you try to fit everything in. The skill is drawing the line cleanly and shipping.
Rank by Impact First
Start with impact, how many players a bug affects times how badly it hurts them. Occurrence counts give you the reach directly; severity you assign. This ranking does most of the work: the high-reach, high-severity bugs obviously belong in the update, and the low-reach, low-severity ones obviously can wait. The cut line mostly draws itself once the list is ordered by impact.
Bugnet's occurrence data makes the reach axis objective, so your update planning starts from 'here are the issues sorted by how many players hit them' rather than from a gut sense of what feels important. That ordering turns a vague debate into a clear ranked list to draw a line through.
Weigh Impact Against Effort
Impact alone is not the whole story, effort matters too. A high-impact bug that needs a risky rewrite might be too dangerous to rush into this update, while a moderate-impact bug that is a one-line fix is easy to include. Plot impact against effort and the update almost plans itself: do the high-impact, low-effort fixes for sure, include high-impact high-effort ones only if you have the time to do them safely, and skip low-impact high-effort ones entirely.
Be especially wary of cramming a risky high-effort fix into an update under time pressure, that is exactly how updates introduce regressions. Sometimes the right call is to defer a big fix to the next update so it gets the testing it needs, rather than rush it and break something.
Draw the Line and Ship
Once issues are ranked by impact and filtered by effort, draw an explicit cut line for this update and commit to it. Everything above ships; everything below is deferred, consciously, to the next one. The discipline is in not letting the line creep, every extra bug you squeeze in delays the update and adds regression risk. A shipped update fixing the top issues beats a perfect update that never ships.
Deferring is not failing, it is planning. The bugs below the line are not abandoned; they are queued for the next update, where they will be reconsidered against whatever new reports have arrived. Drawing a clean line and shipping on cadence is what keeps your updates regular and your players seeing steady progress, which matters more than any single update being comprehensive.
An update is a container, not a backlog. Rank by impact, draw the line, ship, and defer the rest without guilt.