-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
CAR Team 2026-06-22
-
None
-
None
-
None
-
None
-
None
-
None
-
None
This is a behavior-preserving refactor of resmoke's multiversion handling. Today the logic that derives old-version binary names and the set of versions to test against is scattered across module-level constants and helper methods in multiversionconstants.py and MultiversionService, with duplicated copies cached on the fixture config. This makes the source of truth unclear and forces eager computation of version constants at import time.
The goal is to make MultiversionService the single source of truth for multiversion binary-name and version-list resolution. Concretely:
- Centralize binary-name construction. Fold the separate build_last_lts_binary / build_last_continuous_binary helpers and the module-level get_binary_name_for_version dispatcher into a single MultiversionService.get_binary_name_for_version() method keyed by MultiversionOptions.
- Replace the OLD_VERSIONS module constant (here) with a MultiversionService.get_old_versions() method carrying the same last-LTS / last-continuous / EOL logic.
- Lazily compute and memoize version constants. Rename calculate_version_constants to a memoized get_version_constants() so the data files are read once, on first use, rather than eagerly at import.
- Introduce plain binary base names config.MONGOD_BIN_NAME / config.MONGOS_BIN_NAME. Binary-name construction must use the bare names (mongod, mongos) rather than DEFAULT_MONGOD_EXECUTABLE, which may be resolved to an absolute executable path.
- Remove the now-unused module-level binary constants (LAST_LTS_MONGOD_BINARY and friends) and their duplicated copies on the fixture config.