SemVer bump for a non-breaking bug fix

WHAT THIS TESTS This checks fluency with Semantic Versioning, which underpins safe upgrades across consuming teams. The interviewer wants the correct level and the reasoning, since miscategorizing erodes the trust SemVer is meant to provide.

A GOOD ANSWER COVERS SemVer uses MAJOR.MINOR.PATCH. You increment MAJOR for backward-incompatible (breaking) changes, MINOR for new functionality added in a backward-compatible way, and PATCH for backward-compatible bug fixes. A non-breaking bug fix to the button is therefore a PATCH bump: for example, 2.4.0 becomes 2.4.1. The reasoning is that the fix corrects behavior without changing the public API or breaking existing usage, so any consumer can upgrade safely with no code changes. State the upgrade contract explicitly: patch and minor releases should be safe to adopt, while a major signals consumers must read a migration guide. Note the trust dimension: if you over-bump fixes to minor or major, teams cannot rely on the numbers to judge upgrade risk, and if you under-classify breaking changes as patches, you silently break consumers.

COMMON WRONG ANSWERS Calling a simple fix a minor because it changed code, confusing fixes with features. Bumping major out of caution, scaring consumers needlessly. Conversely, hiding a behavioral change that is actually breaking under a patch. Forgetting that visual changes can be breaking even when the API is unchanged.

LIKELY FOLLOW-UPS When would a button change be a major instead? What about a visual change with no API change? How do pre-release tags fit in?

ONE CONCRETE EXAMPLE The button fired its onClick twice on touch devices; you fix the handler without changing its API. Since existing usage is unaffected and the public interface is identical, you release it as a patch, 3.1.2 becoming 3.1.3, and consumers upgrade with no changes.