A shared networking module has released a new major version with breaking changes. Dev, staging and prod each call the module from their own root configuration with an exact version pin. The team wants the new version to reach production gradually and to be easy to roll back. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
Treat a major version like a new recipe: you try it in the test kitchen before serving it to customers. Bump dev first, then carry the exact same version forward one environment at a time. If something tastes wrong, you just roll back that one pin.
Full Explanation
Exact version pins make the module code each environment runs explicit, so promotion becomes a sequence of small, reviewable changes. Raising dev's pin first exposes the breaking changes in the least critical environment, where plans and tests reveal required input changes, moved resources or replacements. Once dev is stable, separate changes promote the same pin to staging and then prod, each with its own plan review and its own trivial rollback: revert the pin and apply. Changing every environment in one merge removes the gradual rollout and makes a failure hit production at the same time as dev; plan review helps, but it is not a substitute for running the new version somewhere first. Tracking the main branch abandons versioning, so untested commits would flow everywhere. A minimum-only constraint lets each environment jump to whatever release is newest whenever it reinitializes, which is neither gradual nor controlled. Exam caveat: major releases may include moved blocks or require state refactoring, so read the module's upgrade notes before the dev bump. Operational check: before promoting to prod, confirm the staging plan for the new pin shows only the expected changes and that its apply succeeded.