Backporting a critical fix to an older major

WHAT THIS TESTS Whether you grasp long-term support, maintenance branches, and semantic versioning, and can choose the lowest-risk path that still ships the accessibility fix.

A GOOD ANSWER COVERS First separate the need from the cost: the team needs one fix, not the entire new major. Forcing a major upgrade under deadline imports breaking changes and risk for no reason. The clean solution is a backport: cherry-pick the accessibility fix onto the maintenance branch of the older major and publish it as a patch release, which the team can adopt with no API changes. This depends on having a support policy that keeps the previous major maintained for a defined window, with maintenance branches per supported major. Strategically, agree on the backport, then schedule the major upgrade for after the deadline, perhaps with a codemod to ease it. Communicate the support window so this is a policy, not a one-off favor.

COMMON WRONG ANSWERS Insisting on a full major upgrade now, risking the deadline. Telling the team to monkey-patch or fork, which fragments and creates maintenance debt. Refusing because the fix only exists on latest, ignoring backporting. Having no support policy, so every such request is ad hoc. Shipping the backport as a breaking change.

LIKELY FOLLOW-UPS How long do you support previous majors? How do you manage maintenance branches and cherry-picks? When do you decline a backport? How do you ease the eventual major upgrade?

ONE CONCRETE EXAMPLE The fix landed in v5, the team is on v4. Because v4 is within the support window, you cherry-pick the focus-trap accessibility fix onto the v4 maintenance branch and release v4.7.1, a patch. The team upgrades with zero breaking changes before their deadline, and you jointly schedule the v5 migration for the next quarter.