In an ideal world, we are able to eliminate the window between branch cut and updating FCV constants. This way, we can run multiversion between the new versions before teams push new changes.

One way to ensure that updating FCV constants happens quickly after branch cut is creating a new evergreen variant that continuously runs multiversion tests using a future git tag (SERVER-51407). To avoid having to change the git tag on every release, we can set the tag to some large version like 100.0.0-9999. This value will also need to be added to the releases.yml data file for this suite.

Let's say we are still developing on 6.0. The suite would be running multiversion with future FCV nodes against 6.0 nodes. However, since the v6.0 branch doesn't exist yet, evergreen will fetch the last compiled mongo binaries on master and label them as 6.0 nodes (this feature was added as part of SERVER-59116). So we're effectively testing master against master, with future FCV constants. This should notify server engineers of any breaking changes that would normally only be revealed upon the next upgrade. By testing this throughout the development cycle, we should be able to avoid running into these errors when it comes time to branch cut and upgrade FCVs.

After branch cut but before updating FCV constants, this suite is still being run with the future git tag, so it's still testing future FCV nodes against 6.0. However, at this point the v6.0 branch has been created, so we're using the actual newly-created 6.0 binaries. As a result, we can use this suite to catch any breaking changes that server engineers make while we're working on updating FCV constants (the situation described above)

The suite should be run occasionally during the 6.0 development cycle. After the 6.0 branch cut, it should be run continuously to ensure that no breaking changes are made. After FCV constants have been updated, we can go back to running occasionally.