Background

The dirty-restart compatibility scope (-d) runs test_dirty_restart for every ordered pair of branches in UPGRADE_TO_LATEST_UPGRADE_DOWNGRADE_RELEASE_BRANCHES. The pairing is a naive N×N double loop in compatibility_test_for_releases.sh:1158-1164:

for b1 in "${upgrade_to_latest_upgrade_downgrade_release_branches[@]}"; do
    for b2 in "${upgrade_to_latest_upgrade_downgrade_release_branches[@]}"; do
        if [[ "$b1" != "$b2" ]]; then
            test_dirty_restart "$b1" "$b2"
        fi
    done
done

This list does not include develop, unlike the NEWER scope, which uses version-aware pairing logic (add_pair, lines 886-932) that treats develop as a proxy for the next/upper-adjacent major release.

Problem

Because develop is excluded, the newest-tip code is never a dirty-restart source against older releases — until a new release branch is cut from develop and added to the list. At that point the tip's behavior is exercised for the first time, and any latent forward/backward-incompatibility surfaces as a surprise failure attributed to the branch-add change rather than to the underlying code.

This is exactly what happened with WT-18096: adding mongodb-9.0 (built from develop) generated the brand-new pairs 9.0->7.0 and 9.0->6.0, which exposed a pre-existing test/format prefetch-config incompatibility (WT-16671) and forced a revert. Had develop been in the dirty-restart list all along, the incompatibility would have been caught continuously on mainline instead of at branch-cut time.

Proposal

Add develop to the dirty-restart branch list, treating it as "the future new release branch," so the newest-tip code is always paired against the supported older releases.

Considerations

• develop has no numeric version, so branch_major_version / branch_minor_version return empty for it. The current all-pairs loop has no ordering notion, but any move toward version-aware pairing (to avoid redundant/nonsensical pairs) will need to handle develop as the highest version — mirroring how add_pair already uses it as a proxy for the next major.
• Confirm whether the existing version-sorting helpers are sufficient or need extending (per discussion, this logic may have been partially removed).
• Verify this doesn't create redundant coverage against whatever the newest release branch is at any given time (e.g. develop and mongodb-9.0 both being tip-adjacent).

Related

WT-18096 (branch-add that triggered the revert), WT-16671 (prefetch config change), WT-12978 (prefetch=0 compat suppression).