Handling version mismatches across a team
A version mismatch is an annoyance for one person and a process problem for a team: who downgrades, when, and who signs off on the result. Agreeing on the rule up front beats firefighting every time.
Option one: agree on one version
The cheapest long-term answer. Before the project starts, confirm what everyone has and take the oldest as the baseline. The downside is that it pins the whole team to an older release — nobody can move up alone.
Option two: downgrade on delivery
Everyone works in their own version and delivery is downgraded to the recipient’s version. Maximum flexibility, at the cost of an extra step each time plus someone confirming nothing important was dropped.
Option three: master plus branch
Keep the highest-version project as a long-lived master and derive a downgraded branch for each downward delivery. The master stays complete and the downgraded copy is just for older environments. This is the steadiest pattern for long projects with a wide version spread.
The part people miss
Version alignment is not only about the main application. Plugins and third-party effects are version-bound too — align the application but not the plugins and the project still will not open. Write plugin versions into the rule as well.