How do I know which update caused a crash?

Track crashes by game version. A crash that's new on the latest version is tied directly to that release, so when a crash appears or a crash rate jumps right after an update, version tracking confirms the update introduced it. That tells you what changed (the diff between the last good and first bad version), narrowing your investigation. Without version tracking, you can't tell when a crash started, so attributing it to an update is guesswork.

Should I roll back or fix an update that's causing crashes?

It depends on severity and speed. If the crash is serious and widespread and you need players on a working version immediately, rolling back to the previous known-good version is often fastest. If the issue is contained and quick to patch, fix forward with a hotfix. Per-version crash tracking tells you the update caused it and which version was last good, so you can decide fast. Often the best path is roll back to stop the bleeding, then fix forward properly.

What Causes Crashes After an Update?

Quick answer: Crashes after an update are usually regressions, the update introduced a bug. Common causes are changed code with unintended side effects, save or data incompatibility, and new features with defects. Version tracking ties it to the update.

When crashes spike right after you ship an update, the update is almost certainly the cause, you introduced a regression. Understanding how updates cause crashes helps you find and fix them fast. Here's what causes crashes after an update.

How Updates Introduce Crashes

An update changes code, and changes have side effects, so a new crash after an update is usually a regression the update introduced. The common ways this happens:

Changed code with unintended side effects, a fix or feature that breaks something elsewhere
Save or data incompatibility, the new version can't correctly read saves or data from the old one, crashing on load
New features with defects, freshly-added code that has its own bugs
Changed dependencies or assets, an updated library or asset that behaves differently
Removed or renamed things, code or data the update removed that something still relies on
Migration bugs, errors in converting old data or state to the new version's format

Each is a way the update broke something that previously worked, the definition of a regression, which is why crashes appearing right after an update point at the update.

Why Version Tracking Pinpoints the Cause

The key to crashes after an update is knowing which update, and tracking crashes by version gives you that. A crash that's new on the latest version is tied directly to that release, telling you the update introduced it and pointing at what changed.

Bugnet tags every crash by version and tracks crash rates per build, so a regression shows up as a new issue or a crash-rate jump on the latest version. This is what turns 'crashes after the update' into 'this specific update introduced this crash,' which narrows your investigation to what changed.

Finding and Fixing the Regression

Once you know an update caused the crash, you know what changed, the diff between the last good version and the first bad one contains the cause. That narrows your investigation dramatically, and you can decide to fix forward or roll back to the previous version.

Bugnet's per-version attribution hands you that starting point, so you fix the regression while the context is fresh. So crashes after an update are caused by regressions the update introduced, and version tracking is what ties the crash to the update and points you at the cause to fix.

Crashes after an update are usually regressions, from changed code's side effects, save/data incompatibility, or new feature defects. Version tracking ties the crash to the update and points at what changed.